Liberating a chinese robot, to then control it with a chinese LLM

But to get to this we have to start our journey at the beggining:

import asyncio
from bleak import BleakScanner

async def main():
    devices = await BleakScanner.discover()
    for d in devices:
        print(f"Device: {d.name}, Address: {d.address}")

asyncio.run(main())

This simple scan checks whether the robot appears at all. It did not. A deeper scan with a callback that prints advertisement fields exposed the important piece: manufacturer-specific data. That led to the company ID we later matched to 0x53A6.

I tried the usual approach: connect with BleakClient, enumerate services, and look for writable characteristics. That did not work. There were no useful writable channels and no GATT writes in the captures.

To see what the official app actually does, I used Android’s Bluetooth HCI snoop log:

1. Enable Bluetooth HCI snoop log in Developer Options.
2. Drive the robot with the app and record a session: idle, forward, reverse, left, right, stop.
3. Pull the btsnoop_hci.log from the phone using adb or a bug report.
4. Open it in Wireshark.

The capture showed no GATT connections. Instead, the phone repeatedly set its advertising packet and re-enabled advertising roughly every 40 ms. Each advertisement carried a Manufacturer Specific Data field (type 0xFF) with company ID 0x53A6 followed by a 14-byte payload.

Windows and Bleak can scan these advertisements, but they cannot craft arbitrary advertisement payloads. For that I used a Raspberry Pi and raw HCI sockets (AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI). From the Pi I pushed LE Set Advertising Data and LE Set Advertise Enable packets at the same rate the phone used.

When the Pi started sending matching frames, the robot’s LED went solid and it accepted the controller. Replaying a few captured payloads made the wheels move.

At that point three facts were clear:

• BLE advertising is the transport.
• The manufacturer format and company ID match the capture.
• The robot interprets manufacturer data as commands.

Only decoding the payload remained.

Early replays sometimes moved only one wheel. That turned out to be checksum errors in the replays. Once frames had correct checksums, control was reliable.

What I found:

• The frame set contains only nine distinct command frames. These match all combinations of two ternary wheel states.

• Each wheel has three states: stop, forward, and reverse. There is no proportional speed.

• One byte (B7) encodes both wheel states: B7 = 0xC0 | (left << 2) | right.

• Byte 11 is a checksum equal to the population count of B7: CK = popcount(B7).

  The 31-byte advertising buffer looks like this: flags 02 01 05, manufacturer header len 0xFF a6 53, 14-byte payload, zero-padded to 31.

  Manufacturer payload example (14 bytes) is shown below.

Idle beacon differs slightly:

ae 00 00 00 00 00 00 00 00 00 00 00 e1 99

The wheel byte layout:

bit:  7 6 5 4 3 2 1 0
      1 1 0 0 L L R R

The able of frames and meanings can be found in the detailed protocol writeup on my github. Cause all of this I open-sourced as an SDK so that anyone can “liberate” their iM.Master robots.

The decoder and builder are in immaster/protocol.py and the broadcaster in immaster/driver.py.

  from immaster.protocol import build_frame, decode_frame, Wheel

  build_frame(Wheel.FWD, Wheel.FWD).hex()   # -> 'ae4a0700000000c50000c504c399'
  decode_frame(bytes.fromhex('ae4a0700000000c90000c904c399'))  # -> (REV, FWD)

The protocol is considered fully reverse-engineered.

The next step is to now make a qwen model actually control the robot. Im using an old phone for the camera and microphone. Using a simple browser to connect to the server running on the RPI which contains a qwen LLM and a hailo vision model. The vision model fetches frames from the IP camera which is running on the phone, and the LLM gets prompts from the phone aswell through the web-app (served on the RPI, opened on the browser on the phone). This makes for a very DIY-ed hacky-scrappy pipeline but it works!