In my last update, I described the direction for ECITON-R: helping robots use their own information to make useful communication decisions. Since then, I’ve connected the first direct-message decision to execution in the interactive simulator, Swarm Lab. I can now follow a choice from the sending robot through to what the receiving robot learns.
The clearest example is a small simulated scene. One robot knows about a task that another robot has never sensed. The first robot sends that task information directly to its neighbor. When the message arrives and passes the receiver’s checks, the task enters its local knowledge and becomes its next goal. The recorded events let me trace that change back to the original message.
I also checked what happens when the sender stays silent or the message is lost. In those cases, the recipient does not gain that task information or choose it as its goal during the comparison. This gives me a concrete way to inspect how communication changes a decision. It is a small software example; broader coordination benefits still need to be measured.
Getting this working involved separating several events that can easily look like the same thing. A robot requesting a transmission, the system accepting it, a message leaving the sender, and another robot applying its contents are all recorded separately. A request can be refused, and an accepted transmission can still be lost. The simulator also accounts for the modeled communication costs and checks whether the selected information is still valid.
The current decision rule is deterministic. A trained local model is still ahead. Having this path working gives me something concrete to compare a future model against: what it chooses to share, what reaches another robot, and what changes afterward. The longer-term question remains whether learned communication can help a team complete useful work within its resource limits.
The Node hardware design has also moved forward. I now have a compact PCB design built around a Nordic processor module and a separate LoRa radio, with USB-C power and data, host connections, and provisions for measuring core power use. The schematic, layout, manufacturing files, and parts list have been reviewed. This is still a design milestone: the board has not been assembled or physically tested, and the Nordic firmware work remains open.
Back-side CAD preview of the ECITON-R Node A2 PCB, showing routing and connector labels. The board has not been assembled or physically tested.
The next physical demonstration is cooperative sensing and reporting. The plan is for field nodes to take readings, share information that affects a peer’s next sensing action, and report through peer relays to a receiver and laptop gateway into Dispatch. On a robot, the host’s existing navigation, motor control, and safety systems would retain responsibility for movement.
I’ve also brought the simulator, firmware, hardware, Dispatch, and AI plans into one shared development baseline. That makes the dependencies clearer: establish the sensing contracts, verify the target hardware and software, and demonstrate the complete reporting path before moving into AI training. My next goal is to make that physical chain as understandable as the simulated one, with a clear record of what was observed, sent, received, and acted on.