Embedded systems · Project case study

ResQ · Robot-to-robot communication

Two microcontrollers exchange 8-byte encrypted search-zone messages, supported by custom Zigbee framing and a compact EEPROM map.

DisciplineEmbedded systems

StatusIn progress

Year2026

Project overview

STM32F411REEmbedded CXBee S2CZigbee API mode 2UARTI²CEEPROMAES-128-CTR

8 bytesEncrypted application message · 3 header bytes + 5 ciphertext bytes

ResQ / Communications architecture

Robot ANucleo-F411RECoordinator · XBee S2C

↔Zigbee

Robot BNucleo-F411RERouter · XBee S2C

Robot A → I²C → 24LC64 EEPROM 256-byte zone map

UART connects each MCU to its radio · 8-byte encrypted application payload

ResQ is my embedded communications prototype for urban search-and-rescue coordination. Two Nucleo-F411RE boards represent reconnaissance robots sharing information about search zones. It is a separate communications coursework project from the ResQ868 quadruped.

Watch demo

The engineering

The challenge

Coordinate search zones using tiny wireless messages and limited persistent storage, while making communication activity visible and diagnosable on two independent microcontrollers.

My contribution

I developed the custom framing, EEPROM driver, bit-packed zone map and application logic, integrated tiny-AES-c, and documented board bring-up and debugging.

Approach & implementation

I separated radio framing, storage, zone encoding and application cryptography into C modules. The 256-byte map stores state and survivor count in one byte per zone. Serial counters expose transmission, reception and rejection paths; LEDs provide an immediate hardware indication. The development reports describe XBee link-layer AES configuration, alongside the application-layer AES-CTR implementation.

Results & lessons

What the project achieved

The development reports record bidirectional encrypted CLAIM exchanges with successful decryption, and EEPROM read-back after reboot with writes disabled. The zone-map layout is 256 bytes plus an 8-byte header, within an 8192-byte device. Source inspection confirms API-mode framing, page-aware storage and LED event handling. These are bench results documented in the development reports; a demonstration video is also linked below.

Limitations & next steps

The supplied build is a subsystem demonstration. Received messages are logged but are not yet applied to the EEPROM zone map, and application ACK replies are not sent. XBee delivery status is a separate mechanism. Replay tracking currently lives in RAM. The 8-bit counter can repeat after wrap or reboot, reusing an AES-CTR nonce under the same key; the XOR checksum is not cryptographic authentication. Next steps are authenticated encryption, a persistent session/counter design, stronger key provisioning, completed receive-to-storage/ACK handling and measured LED timing. The custom key derivation is described here as a prototype, not as a verified standards-compliant KDF.

Explore the engineering

One zone. One byte.

Pack a search result.

Change the fields to see how the firmware encodes a zone. Two bits hold its state; six hold the survivor count.

Zone (1–254)

State

Survivors (0–63)

bit 71

bit 61

bit 50

bit 40

bit 30

bit 20

bit 11

bit 01

Blue = statePale blue = survivor count

0xC3Survivor · 3 survivors
EEPROM address: 0x00B5 (0x0008 + zone 173)

Interactive explanation of ZoneMap.h’s encoding, using the report’s zone 173 example. This runs in your browser and does not communicate with the hardware. All bit combinations are shown; the application must decide which state/count combinations make sense.

Media & resources

Watch project video

Let’s talk about this project.

I’m happy to walk through the design decisions, challenges and what I would improve next.

Contact Peter

All projects PyroGuard