Close
0%
0%

DJI Robomaster S1 Hacks

My attempt to add inputs and outputs to the Robomaster S1 platform.

Similar projects worth following
My attempt to make the DJI Robomaster S1 more flexible. I'm attempting to understand the communication protocols used in the robot.

I'm attempting to figure out ways of hacking the Robomaster S1 platform. This includes investigating the hardware and the communication protocol used by the robot.

See the Log titled Battery Investigations for photos of the battery internals.

List of Identified Components

Shared Components:

Intelligent Controller, Motion Controller, Hit Detectors, Turret Hit Detectors, Turret Base, Turret Tilt Control:

Maxim Inc. CAN Bus Transceiver MAX3051EKA+Tj: Mouser PartDatasheet(pdf)easier to solder part.

Hit Detectors, Turret Hit Detectors:

STM32F042K6 (Package UFQFPN32): Mouser Part, Datasheet(pdf), easier to solder part.

Turret Base, Turret Tilt Control: 

Brushless motor control MP6536: Datasheet

Single Use Components:

Intelligent Controller:

InnoPower LC1860C: Datasheet

Atheros AR1021X WiFi Chip: USB WiFi Board using this chip (on Aliexpress).

Micron Memory Chip: Unclear about details of chip.

Motion Controller:

Main Microcontroller MIMXRT1021CAF4A: Mouser Part, Datasheet(pdf)

2 x RS-485 Transceiver SN65HVD75DRBR: Mouser Part, Datasheet(pdf), easier to solder part.

Turret Tilt Control:

Atmel ATSAME70N19 Microcontroller: Datasheet.

Thanks to users on the DJI Robomaster S1 forum and to people making comments on this project for the help in identifying many of these parts.

TestCodeUsedToProduceTraces_ScratchConvertedToPython.txt

Test190822a converted from Scratch to Python. Saved as a text file.

plain - 614.00 bytes - 08/30/2019 at 22:50

Download

RobomasterS1_190822b.logicdata

Logic analyzer traces while Robomaster S1 was running program titled "Test190822a".

logicdata - 38.03 MB - 08/30/2019 at 22:35

Download

  • Speaker Teardown

    Duane Degn09/12/2019 at 07:25 0 comments

    For the first time while taking about the Robomaster S1, I thought to stop and document the UV tamper detection system used by DJI. Many of the enclosures which are not intended to be user serviceable have one of the fastener's filled with a bit of UV sensitive glue. The photo below is shows this glue being illuminated with a violet laser. The glue is easily removed but removing the glue lets DJI know the enclosure was likely opened.

    Some of the fasteners have small tamper detection stickers attached to them. I didn't take any photos of the undamaged stickers. The UV glue shown above was the only blob left on my robot when I finally thought to photograph the glue.

    The speaker enclosure is held shut with four Torx head fasteners. Two of the fasteners are hidden under the two rubber pads.

    Once the fasteners are removed, the cover still needs a bit of coaxing to remove.

    Once the speaker enclosure was opened, I was surprised how light the side of the enclosure with the speaker was. It turned out 57.6% of the speaker modules weight was from the enclosure cover.

    The cover has a piece of metal (zinc?) which made the module heavier than needed from just the electronics. The piece with the metal weighed 27.70g of the total module weight of 48.05g. (Weighed to the nearest 0.05g.)

    I'm not sure if the weight is just to make the speaker feel more substantial or if the weight is used to balance the gimbal. The weight likely effects the quality of the sound. The weight could be used to improve the way the enclosure resonates.

    Below is the 4 Ohm speaker removed from the enclosure.

    The speaker is electrically connected to the tip and ring of the tip/ring/sleeve connector. The speaker is held in place with some double sided tape.

    The front grill is also held in place with double sided tape.

    While these parts are clearly not intended to be opened, I was able to reassemble the speaker module without doing any noticeable damage (other than the missing UV glue).

    I imagine the Intelligent Controller is capable of producing stereo sound. Hopefully DJI will make it possible to use the Intelligent Controller to produce sounds beyond the mono sound effects presently possible.

  • Turret Teardown (Tilt Control)

    Duane Degn09/08/2019 at 05:30 0 comments

    The brushless motor on the right side of the turret tilts the Intelligent Controller, gel bead gun and camera. The motor is controlled by circuits located between the tilt mechanism and the brushless motor.

    It's a bit of a pain to reach this PCB. The tilt mechanism needs to be removed. There are three fasteners on the right side of the mechanism which need to be remove.

    There's also a fastener on the left side which needs to be removed.

    The above fastener can be removed with a T10 Torx bit. The hex driver which comes with the Robomaster S1 will work with this fastener in a pinch. I didn't realize it was a Torx socket until I saw this photograph.

    The tilt motor uses the same MP6536 motor control chip as the pan motor. Below is a closeup of the Atmel microcontroller chip.

    To me the text reads Atmel ATSAMEZON19. I haven't found the datasheet for this chip yet.

    Edit: It's a ATSAME70N19. I can easily find the datasheet now.

    The IMU chip is almost readable.

    Based on this Chinese forum post, apparently DJI likes to use the "6500" IMU in other Robomaster products. I assume this would a be a MPU-6500 chip but I'm not positive.

    There is some goop on the underside of the IMU on the PCB. 

    This goop is also on the metal support piece.

    There's a small area walled off to isolate this sticky goop. I believe this thermal compound is intended to bridge the gap from the PCB to the metal support.

    The brushless motor has 15 poles.

    Three of the above screw holes serve an unknown purpose. Without disassembling the motor from the rest for the turret, I haven't been able to figure to what the three fasteners connect. 

    Here's another photo with the three fasteners in position.

    The metal PCB support piece rotates with the motor. The other side of the tilt mechanism rotates around the single fastener with a matching bearing and plastic spacer.

    The fastener is supported by a bearing in the right side of the turret.

    The fastener connects with the central tilt mechanism.

    The geometry of the two mating sections limits the amount of tilt possible.

    The right side of the mechanism mates with the metal PCB base. The right side includes a piece of rubber to secure the brushless motor's power connector.

    One last note about the turret PCBs. There are multiple places where little stainless steel screws are used. Screws with different threads can look very similar.

    The self-threading screws are not used with the tilt portion of the turret. The self-threading screws are used to connect the turret hit detector PCBs the plastic supports. The self-threading screws are also used to secure the IR shield to the IR daughter boards connected to the turret hit detectors. See earlier log for turret hit detector tear down.

  • Turret Teardown (Pan Base)

    Duane Degn09/08/2019 at 01:01 7 comments

    The cover of the base is held in place with three T5 Torx head fasteners.

    The two black CAN bus connectors are used to allow more current to pass to the turret. The turret uses a lot of the S1's power. The Intelligent Controller, gun, and brushless motors all are relatively power hungry devices.

    Besides the two 4-pin black CAN Bus connectors, there are three other CAN Bus connectors on the turret's base PCB. I figured out the purpose of five of the ten positions of the black 10-pin connector. The ten wire cable passes up the right side of the turret to the turret's tilt controller. There are two four wire CAN Bus cables which connect the turret's hit detectors to the base PCB. The connector marked with blue ink is used to connect the left turret hit detector.

    The large square chip near the brushless motor connector is likely the brushless motor controller. After I scrapped the coating off the chip, I was able to a couple good photos of the markings.

    I'm pretty sure the top line is MPS1839 and the second line is MP6536. Here's a photo from a different angle.

    I think the second line is easier to read in the above photo than the first one I posted. I haven't been able to figure out which parts these are. I'll edit this log if someone is able to identify this chip.

    Edit: Thanks to Bruno Albuquerque for finding a datasheet for the MP6536 chip.

    The conformal coating makes identifying chips difficult. I believe the largest chip in the photo above is the microcontroller for this board. 

    Edit: The microcontroller chip has the following markings:

    Top Line: GD32F 33G

    2nd Line: C8T6

    3rd Line: BK52KQ

    4th Line: JJ1831

    Bottom Line: Some sort of logo and the text "ARM"

    The main reason I suspect the highlighted chip is a CAN Bus transceiver is the 8-pin SON-8 package. So far the other CAN Bus transceivers appear to each have 8 pins. This may be the SN65HVD75DRBR RS-485 transceiver chip which is also used on the Motion Controller board.

    Above is the inside of the base enclosure. The connector to the brushless motor can be seen in the left side of the photo. This connector is held in place with a rubber pad on inside of the base's cap.

    There's a another "cap" like covering one the top side of the turret base.

    Wires to the turret hit detectors are routed through this space. The ten wires which connect to the tilt PCB are also routed here.

  • Turret Teardown (Hit Detectors)

    Duane Degn09/05/2019 at 15:47 0 comments

    Notice: Removing the side panels will likely void your warranty. There are multiple types of tamper indicators. There are little white stickers and also little globes of glue in fastener heads. I personally think you don't own a product until you've voided the warranty.

    The turret side panels are secured with 7 star (Torx?) type fasteners. The bit I used to remove these fasteners is labeled "T5." Two of the seven side fasteners are  located under the dark red filter. These dark red filters are not easy to remove without marring the plastic.

    Once the seven fasteners are removed, the side panels may be pulled off without too much effort. The side panels will remain securely attached without use of the fasteners. Below is a photo of the inside of the right side panel. The left panel is a mirror image of the right panel.

    The white translucent material appears to be securely glued in place. I didn't see any obvious excess glue but the translucent plastic acts as if it's completely merged with grey plastic.

    Each side contains a PCB with two IR transmitters and three IR receivers.

    The PCB has a plastic plate on the bottom. Part of the purpose of this plastic plate is to allow a path for the tilt control wires on the right side.

    The above photo shows the PCB upside down. The two stainless steel screws are self threading and hold the PCB to plastic support piece. If anyone reading this takes about their gimbal, be aware there are multiple screws which are very similar but use different threads.

    The left and right turret hit detector PCBs are not mirrored. The PCBs and plastic support piece are identical. The path for the tilt control wires on the right side, is oriented in such a way as to only work correctly on the right side of the turret.

    The white CAN Bus connector is 0.05" (1.27mm) pitch. The four conductor ribbon connects to the back of the PCB at solder pads spaced 0.1" (2.54mm). 

    The two small stainless steel screws secure the IR receivers and IR LEDs to plastic support tray under the main PCB. A third small stainless steel screw secures the daughter PCB to the black plastic shields.

    Here's a photo of the bottom of the PCB.

    Above shows the plastic support still attached to the PCB.

    Above shows the PCB side of the plastic support.

    Without the plastic support the route of the tilt control cables is easier to see.

    The turret hit detectors apparently use the same microcontroller as the main body's hit detectors.

    The left and right turret hit detector PCBs are nearly identical. The only difference I've found is in the last four digits of the text printed on the board. The text on the right PCB ends with "19 1303" while the text on the left PCB ends with "19 0801." 

    As I noted on on the photo, the IR daughter board connects with a 6-Pin 1mm pitch header.

    As you can see the right IR PCB has text ending with "1908 11." The left IR PCB has text ending with "1919 09."

    The IR LEDs are not directly driven from the microcontroller. There are transistors which are connected to the anodes of the IR LEDs. Based on the number of pins and the number of components on the daughter board, I suspect the LEDs are controlled in parallel.

  • Intelligent Controller

    Duane Degn09/03/2019 at 21:25 0 comments

    I've opened up the Intelligent Controller. This is the small computer which sits at the top of the S1's turret. The Intelligent Controller has three USB C type connectors. One of these connectors is used with the camera. I don't know how the other to USB C connectors are intended to be used. It's possible one could be a video display connection and one could allow a keyboard and mouse connection but these are guesses on my part.

    The Intelligent Controller also has a micro SD card slot at its front. According to the documentation, it can accept SD cards up to 64 GB.

    Opening the enclosure is relatively easy. I just used the tool which came with the S1 to remove the four hex screws.

    Edit: I had previously incorrectly labelled the Micro USB connector as a USB C connector. The above photo shows the corrected label.

    There I two WiFi antennas which connect under the black square of tape. 

    The PCB is held in place with four stainless steel Phillips head screws. Four black Phillips screws hold the heat sink to the board.

    A removable metal shield covers an area of the PCB. There isn't anything very interesting under this shield. It looks like most of the parts under the shield are passive components. (Note the PCB was rotated 180 degrees between taking the photo above and the photo below. The two photos were taken with different cameras.)

    The top of the PCB has two shielded areas. A heat sink partially covers both the shielded areas. There's a shield over the SD card slot but this shield is not removable.

    Edit: I had previously used a photo which incorrectly labelled the Micro USB. The above photo should be correct.

    There's a lot blue thermal paste between the heat sink and the top of the metal shields.

    Like the metal shield on the bottom of the PCB, the metal shields on top of the PCB are also removable. More blue thermal paste sits between the shields and many of the chips being cooled.

    I attempted to clean the chips in order to read their labels.

    I wasn't able to read the label of the two chips without thermal paste. Here's the best photo of my attempts to capture the text on these chips.

    My initial guess was these were some sort of memory chips. I don't think they are memory chips though. Since they share the shielded area with a WiFi chip, my latest guess is they're used with the WiFi radio. Sorry I wasn't able to get a better image of the label.

    Here's a closeup of the nearby WiFi chip.

    Below is a photo of the smallest of the three chips under the other metal shield.

    A quick search suggests this is a power management chip which is also used in DJI's Mavic Pro.

    Next to the above chip is another Leadcore chip.

    This is obviously an "ARM" processor of some sort. My initial search suggests this is a dual-core 32-bit processor with a modem. One document states its max clock frequency is 1200 MHz. I'm guessing this is the main "brain" of the board and robot.

    Edit (September 6, 2019): As Bruno Albuquerque pointed on in a comment, the LC1860C us a quad-core processor. It runs at 1500 MHz. Thank you Bruno.

    The third chip under this shielded area is shown below.

    This is a Micron chip. I think the part number is MT29TZZZ4D4BKERL-125 W.94M.

    I think this is an eMMC memory chip but I'm not sure about this.

    Here's a photo of the inside of the enclosure without the PCB.

    The fan pulls air in from the two sides, blows it through the heat sink and the air exits out the back. Both the intakes and exhaust opens are covered with thin metal with lots of very small holes which acts as a filter/dust barrier.

    Edit(210330): Wardword reports on the DJI forum than the USB-C cable used with the camera appears to be unique to this device.

  • Hit Detectors

    Duane Degn09/02/2019 at 21:22 3 comments

    console-beaverThe hit detector enclosures are held together with friction only. I think it's hard to open a hit detector without marring the plastic. I personally would rather take something apart rather than keep it pristine. Here are some photos of the open hit detector.

    The PCB is held in place with two screws. I replaced the screw in the enclosure to reduce the chance I'd lose them.

    Here's a photo of the top of the PCB. 

    The PCB has a conformal coating. I think there are three resistors next to each of the eight LEDs. This makes me think the LEDs are not the individually addressable sort. I think all the LEDs in one hit detector have to have the same color combination. It appears hit detection is done with sound.

    The 8-pin chip at the microphone's 10 o'clock position is likely a CAN bus transceiver. I think it converts between CAN Bus differential signals and signals the on board microcontroller can use.

    Here's a photo of the bottom of the PCB.

    I was surprised to see the microphone connected with wires.

    The conformal coating makes reading chip labels extra difficult. I scrapped the coating off the largest chip and took a photo.

    If anyone figures out which chip it is, I hope they let me know. I may attempt to get better photos with a microscope and using a different hit detector. Maybe I can read the text better with the coating in place by using a light at a proper angle.

    Edit: As pointed out by console-beaver and postart168 the chip is a STM32F042K6 ARM Cortex-M0 MCU. postart168 even provided the datasheet page number to seeing the markings. Thanks to both of you.

    Here's the datasheet link.

    Edit: I recall why I didn't initially think this was the Arm chip identified above. According to page 26 of the datasheet, the CAN bus is good up to 1Mbps. The CAN on the Robomaster S1 is 2Mbps according to multiple traces I've captured using a Saleae Logic Analyzer. There a logic analyzer file included in the file section of this project.

  • Sniffing Adapters

    Duane Degn08/30/2019 at 23:48 0 comments

    The CAN Bus may be sniffed by connecting to any unused CAN Bus connector. There's an unused connector at the top of the turret under a rubber plug. Any of  the hit detectors may also be used to tap into the CAN Bus.

    The CAN Bus connectors use a pair of differential signals similar to the RS-485 protocol. The other two pins of the Can Bus connection are ground and power (~12V). I use the following pin numbers when describing the connector.

    Since CAN uses a differential signal, I tried using a RS-485 transceiver chip in an attempt to get a signal my Saleae Logic Analyzer could read. I had used the ISL3178EIBZ chip in several previous projects so I used a couple of PCBs with these chips to listen in on the CAN Bus and the M Bus. Here is a diagram of the pinouts of the chip.

    I connected the logic analyzer to pin 1 of the RS-485 chip.

    While there are lots of locations where the CAN Bus may be accessed, the M Bus doesn't have similar locations to tap into the signal. I found if one motor is disconnected, none of the motors would power on so I wanted to find a way of sniffing the M Bus will all four motors connected.

    Here's  a picture of a single pin and a two pin adapter I used to sniff the M Bus.

    The first photo I took trying to show this adapter in use wasn't very clear so I made a second attempt of showing the adapter pins in use. I'm including both photos in hopes at least one will provide convey how the adapter is used.

    The adapter pins where made by soldering a right angle header to an double length header. This  resulted in a three way header pin.

    In order to limit the number of parameters changing, I wrote a custom Scratch program to turn a single motor on at a few different speeds. Here's a screen grab of the Scratch program.

    Here's the Python translation.

    variable_motorSpeed = 0
    def start():
        global variable_motorSpeed
        robot_ctrl.set_mode(rm_define.robot_mode_free)
        while True:
            variable_motorSpeed = 20
            chassis_ctrl.set_pwm_value(rm_define.pwm1, 8)
            chassis_ctrl.set_wheel_speed(variable_motorSpeed,0,0,0)
            time.sleep(0.5)
            variable_motorSpeed = 40
            chassis_ctrl.set_pwm_value(rm_define.pwm1, 9)
            chassis_ctrl.set_wheel_speed(variable_motorSpeed,0,0,0)
            time.sleep(0.5)
            variable_motorSpeed = 0
            chassis_ctrl.set_pwm_value(rm_define.pwm1, 7.5)
            chassis_ctrl.set_w

    I added PWM commands to help identifying which section of code was being executed. I included the PWM1 output in the logic analyzer capture. I've included the logic analyzer data file in the "Files" section of this project. Here's a screen grab of a portion of the captured traces.

    **Edit (9/1/19): I'm not so sure about the M Bus baud. It may not be exactly 921,600 bps.**

    From analyzing the traces, I've learned the M Bus uses a baud of 921,600 bps (edit: unsure about this). The CAN Bus uses 2,000,000 bps.

    DJI has several open source development boards. Hopefully the communication protocol used by the open source boards is similar to the S1's protocol. Here's a link to DJI's Github. DJI's development boards can be found at DJI's store as well as some other online robotics stores.

    The above traces include the I2C lines used to communicate with the battery. Reddit user ReasonablyClever shared information he gathered from investigating this bus in the RobomasterS1 Reddit.

    As ReasonablyClever found, the S1 will not work properly when powered from a different source than a Robomaster Intelligent Battery.

    I've found the I can greatly extend the operational time of my S1 by wiring an external power supply in parallel with the battery. I make sure the external power has a matching voltage and robot doesn't complain as it used the combined power sources. While the normal battery has to be used, the external supply keeps the battery from being drained. An external power supply is really useful when experimenting with code and while attempting to sniff communication lines.

  • Charger Investigation and Modification

    Duane Degn08/30/2019 at 23:30 0 comments

    I couldn't find an easy way of opening the charger. I just started cutting with had tools until I had an opening large enough to force a screwdriver inside. I eventually cut and pried the charger open.

    I was surprised to see only three connections going from the battery to the charger. The connector used by the robot for the I2C clock is not used by the battery charger. The I2C data line is labeled "IO" on the charger PCBs.

    Since my battery was no longer easy to remove from the robot, I wanted a way to charge the battery without removing the battery from the robot.

    I soldered three wires to main charger PCB.

    I made a custom connector to connect the three wires to the S1's Motion Controller board. Below is a photo of the connector before adding Polymorph insulation.

    I used some aluminum foil to 2mm pitched portion of the robot's power connector to use as a mold to form my Polymorph adapter. Once the Polymorph had cooled, I was able to remove the foil.

    This allows the S1's battery cable to plug into the charger. This should allow the battery to be charged while still in the robot.

    I need to put the robot back together in order to test if I can really charge the battery without removing the battery from the robot.

    Edit (9/2/19): I tested charging the battery while installed in the robot and it worked as expected.

    Edit (9/3/19): Here are a few more photos of the charger after the mod.

    Charger closed.

    While I had to cut a bit of a slot in order to make space for the wires to attach to the PCB, the charger enclosure looked pretty bad after my brutal method of opening the enclosure. Some of the gouges are visible in the above photo but the photo below reveals more of the damage done to the enclosure.

    I suspect I voided the warranty.

    After opening a stubborn enclosure like this charger, I often find there was an easier way I could have opened the device. In this case, I don't think there was a way to open the device without significant cutting. The enclosure was very firmly welded shut. I could have made the cuts cleaner but I don't see a way of getting the charger open without cutting plastic.

    The yellow wire carries a data signal. It didn't need to be nearly as thick as the 16 gauge wire I used. I decided to use the thicker wire for cosmetic reasons. Just because the enclosure shows obvious hack marks, doesn't mean I don't want to pretend to care about the aesthetics of the HACK (this was a hack in multiple ways). The three conductor connector is normally used to conduct power to the thee phases of a brushless motor (used in quadcopters and RC airplanes).

  • Battery Investigations

    Duane Degn08/30/2019 at 23:04 0 comments

    I wanted to see inside the Robomaster S1 battery so I pried off the end. Here are some photos of the battery guts.

    Here's the main battery PCB after a short press of the button.

    As can be seen, the battery is made from three 18650 2,400mAh cells. Each cell is labeled LGABHE21865.

    The ten connector interface uses four separate lines. Four connections are used for ground and four connections are used for full battery voltage (about 12V). The two center connectors are used to communicate with the robot. One of these two center connectors is also used to communicate with the battery charger.

    Edit(210327): There's a data capture of the I2C communication on the DJI forum.

View all 9 project logs

Enjoy this project?

Share

Discussions

Anton Dück wrote 07/30/2020 at 08:57 point

If you have canbus issues with you robomaster and your wiring is OK then watch this Video. https://youtu.be/rIiF0I7LT-g it is also a gimba teardown.

  Are you sure? yes | no

Jimccm wrote 05/13/2020 at 11:06 point

Looks like the battery and charger does more than just charging.  It also count the amps charged and use it to calculate the percentage battery left.  I have merged additional 18650s from a 3s configuration to 3s3p and wire them to xt60 for rc charger, charged all to full charge, system only remembers the charge using the original charger.  I then discharge all 3s3p down to 9 volts, and use the original charger, it charged all 3s3p, and now remembers the amps charge and I can run 3 times longer. 

  Are you sure? yes | no

Adam wrote 10/30/2019 at 19:57 point

Can confirm that the Micron chip on the Intelligent Controller is an eMMC storage chip: https://www.micron.com/products/multichip-packages/emmc-based-mcp/part-catalog/mt29tzzz4d4bkerl-125-w

  Are you sure? yes | no

Duane Degn wrote 11/01/2019 at 03:09 point

Thanks for the link.

  Are you sure? yes | no

Joe Ma wrote 10/08/2019 at 15:32 point

Brushless Motor for wheels: M3508I  

    Max Rotational Speed    1000 rpm    

    Max Torque    0.25N·m
     Max Output Power    19 W

I can't find any other similar motor with those specs. Did you happen to measure the phase resistance by any chance?

Thank you for the great work!

  Are you sure? yes | no

Duane Degn wrote 10/09/2019 at 22:18 point

I wasn't able to get the motors apart in order to measure the resistance of the coils.

I removed the c-clip from the back of one of the motors but the motor didn't come apart. I don't see a way of opening the motor.

  Are you sure? yes | no

Ronald Houde wrote 09/09/2019 at 23:35 point

The two chips with the markings that are almost erased are possibly the turret's Intertial Measurement Unit (IMU) accelerator and gyroscopes modules.

  Are you sure? yes | no

Duane Degn wrote 09/10/2019 at 23:01 point

I'm pretty sure the IMU is on the PCB which tilts with the central turret section. It's the same PCB which controls the tilt mechanism's brushless motor.

The IMU PCB is kind a trick to reach. The tilting mechanism has to be removed. There are three small screw on the right internal section of the gimbal which need to be removed to access the PCB. There's also one large fastener on the left side of the gimbal. The fastener on the left side can only be removed after the left side panel and left hit detector are removed. It's a bit of a pain. I've taken my S1 apart to gain access to the PCB and I've taken photos of the IMU PCB but I haven't uploaded the photos to this project yet. I hope to upload these photos soon.

  Are you sure? yes | no

Duane Degn wrote 09/10/2019 at 23:03 point

My initial search suggested it was a WiFi chip. If someone has a link to the datasheet, I'll add the link to my list in the "Details" section. I'll likely add the link you provided until I find a proper datasheet link.

Thanks for your help in identifying the chip.

  Are you sure? yes | no

Bruno Albuquerque wrote 09/06/2019 at 17:57 point

The specs for the ARM chip seem to be:

- ARMv7-A
- Cortex A7
- 4 cores (not 2)
- 1.5 GHz (not 1.2)
- Integrated Mali T628 MP2 @ 600 MHz

https://en.wikipedia.org/wiki/Leadcore_Technology (Search for LC1860C)

  Are you sure? yes | no

Duane Degn wrote 09/07/2019 at 02:02 point

I see you are correcting my initial guesses about the ARM chip in the Intelligent Controller. Thank you. I'll edit the log with correct information.

  Are you sure? yes | no

Bruno Albuquerque wrote 09/09/2019 at 15:55 point

Yep. I should have mentioned I was talking about the intelligent controller. Sorry for the confusion. BTW, did you manage to figure out the memory chips in the intelligent controller? I am wondering how much user memory it actually has (for programs).

  Are you sure? yes | no

Duane Degn wrote 09/09/2019 at 22:57 point

I haven't figured out the memory. I'm pretty sure the Micron chip is the memory chip but I haven't made sense of it.

  Are you sure? yes | no

postart168 wrote 09/05/2019 at 22:04 point

Hi, I think maybe the last photo on the Hit detector section shows an STM32F042K6 ARM Cortex-M0 MCU. Maybe some more photos can validate this. Also the device markings seem consistent with those on the STM32F042x4/STM32F042x6 Datasheet p.104 (https://www.st.com/resource/en/datasheet/stm32f042c4.pdf)

  Are you sure? yes | no

Duane Degn wrote 09/05/2019 at 23:18 point

Thank you very much!

Search for F042K66 did bring up the STM32F042K6 but I didn't look through the datasheet enough to find the markings listed on page 104.

I think this chip is on some of the other PCBs on the robot. Not just the hit detectors.

I'll post some photos of the PCBs used inside the turret soon. I think some of the turret PCBs use this chip as well.

Thanks again for pointing me in the right direction for the datasheet. It was a big help.

  Are you sure? yes | no

console-beaver wrote 09/03/2019 at 23:52 point

thanks for taking apart that "intelligent controller" case and looking at it. Looks like everything there is BGA, oh well. The bottom side of the boards seem to have some test point pads, is there any markings around them that would suggest a serial UART port?

What this switch on a side of the board next to WiFi chip is about? Did you try to connect USB-C port to some host computer to see if this controller present itself as a device?

  Are you sure? yes | no

Duane Degn wrote 09/04/2019 at 03:27 point

I didn't see any marking next to the test points. Some of those test points do kind of beg to be investigated.

The S1 can connect to a phone or computer in two different ways. Either directly as a WiFi hotspot or it can use a WiFi router. Using the router offers some advantages over the hotspot option. The switch on the side indicates which method you want the robot to use.

All my USB-C cables are really short. They're intended to charge cameras or other devices. I'm not sure if they're proper cables or not. The short cables make connecting the PC to the robot a bit of a challenge but I'll likely try it sometime in the near future.

I also want to try connecting the camera to one of the other two USB-C options. I'll be surprised if the camera will work on other connectors but it will be interesting to try.

  Are you sure? yes | no

console-beaver wrote 09/03/2019 at 13:51 point

Can you try to scratch  conformal coating off some of the SOIC-8 chips which you think might be CAN Bus transceivers and try to read the chip markings?

  Are you sure? yes | no

Duane Degn wrote 09/03/2019 at 20:01 point

I've tried this with limited success. I see "AEKF" on top of the small chips. I don't think the CAN Bus transceivers are SOIC. I think they're a smaller package. I think they are SOT-23-8 packages.

As I mentioned in another reply, my best guess is the transceivers are something like this chip: https://www.mouser.com/ProductDetail/595-TCAN330GDCNR

I don't think the markings match but the above chip is the right size and supports 2Mbps baud.

  Are you sure? yes | no

console-beaver wrote 09/03/2019 at 04:10 point

Looking forward to the pix of the "Intelligent Controller" board.

  Are you sure? yes | no

Duane Degn wrote 09/03/2019 at 22:41 point

I just added some photos of the Intelligent Controller to the latest "log." I think the Robomaster S1 uses the same main processor as the Mavic Pro.

  Are you sure? yes | no

console-beaver wrote 09/02/2019 at 19:25 point

Is there any way in Scratch/Python to control the movement of the robot instead of switching on/off individual motors? I.e. can S1 be directed to go left at certain speed? If these commands exist, then we can sniff CAN Bus for corresponding messages and get an idea on how to control it. Turning On/Off individual motors is cool, but then we need to figure how how to control motors for mecanum wheel motion in desired direction with desired speed.

If these commands do not exist, then we can possibly use Robomaster app to control the S1 and sniff the CAN Bus at the same time for corresponding messages?

  Are you sure? yes | no

Duane Degn wrote 09/02/2019 at 20:56 point

The motors can be control individually or the robot can be commanded to drive in a specific direction.

The math to compute individual wheels speeds isn't very hard. I have another project where I directly control the motors of a robot to drive Mecanum wheels.

The direction commands likely originate from the Intelligent Controller on top of the gimbal. The Motion Controller likely computes the individual speeds for each motor. 

I'm still not sure of the best way to hack the robot. Right now I think intercepting the com from the Intelligent Controller and modifying the command before the Motion Controller receives is a good approach. I still need to figure out how to interpret the CAN bus signals in order to do this.

If I can figure out how to send commands directly to the motors, I may leave both the Intelligent Controller and Motion Controller unconnected and just use a microcontroller I know how to use to drive the robot. I would be nice to hack the original controllers but I'm not convinced this is something I can figure out how to do.

  Are you sure? yes | no

console-beaver wrote 09/03/2019 at 00:43 point

I agree that it might be easier to just replace the controller board with something we can control/program. We can use the original setup to sniff on the protocol and then re-implement it in some MCU that has embedded CAN controller.  Are you sure about 2M baud speed on the one of the CAN buses? Can you try to read the marking on a CAN transceiver chip  on S1 motion controller board? Most likely there will be  two chips (same) in 8-pin SOIC packaging...

  Are you sure? yes | no

Duane Degn wrote 09/03/2019 at 03:03 point

I'm sure about the 2M baud of the main CAN bus. The Motor bus is a mix of rates. I think the Motion Controller sends data at 921,600 bps but the motors reply at a slightly different baud.

I've circled a chip on the hit detector PCB which I think is a CAN bus transceiver. I think it's a chip like this one:

https://www.mouser.com/ProductDetail/595-TCAN330GDCNR

The Intelligent Controller has a similar chip in a location appropriate for a CAN transceiver. I'll post photos of the inside of the Intelligent Controller soon. I just finished putting it back together.

  Are you sure? yes | no

console-beaver wrote 09/02/2019 at 15:21 point

Thanks for sharing!

  Are you sure? yes | no

console-beaver wrote 09/02/2019 at 15:20 point

I think LGABHE21865 might have  2500 mAh capacity.

  Are you sure? yes | no

Duane Degn wrote 09/02/2019 at 16:13 point

I wrote 2400 mAh since that's what DJI used on the outside of the pack. If I search Google for "LGABHE21865" I also see the 2500 mAh figure listed. It's nice to see a company understate capacity rather than overstate capacity.

  Are you sure? yes | no

Duane Degn wrote 09/02/2019 at 03:15 point

It has a NXP MIMXRT1021CAF4A chip. Here's the chip at Mouser.

https://www.mouser.com/ProductDetail/771-MIMXRT1021CAF4A

I posted a couple of photos over on the DJI forum.

https://forum.dji.com/forum.php?mod=viewthread&tid=195399&page=2#pid1948544

I have a few photos of the hit sensor boards I haven't posted yet. I'll try to add them to this project within the next few days.

  Are you sure? yes | no

console-beaver wrote 09/01/2019 at 16:07 point

So kool ! I'm thinking on starting hacking my S1 too. Which STM32 MCU does it have on its "motion contorller" (the lower board)? Can you post some high-res pix of the boards?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates