2025/09/16
Rebuild-Z 2025 Sharing Session
Issue 2
A26 Team
Introduction
Hello everyone, today is the second issue of our Rebuild-Z excellent team sharing session! In the first issue, we introduced the A14 team from Track 4 – they prepared for the competition in 5 days, disassembling old robots for parts, and added AI interaction just 3 days before the competition, creating a six-legged robot capable of moving in a wave-like gait, ultimately winning third place in the track, showcasing the real stories of hardware enthusiasts during preparation.
This time, we turn our focus to the A26 team from Track 2, who will share their review on “Multimodal Fusion Robots and Multi-Agent System Design.” This team drew inspiration from large-scale structures in space and delved into multi-agent collective intelligence, achieving not only depth recognition with binocular cameras but also simulating 30 robots with multi-round reinforcement learning, revealing technical breakthroughs and the details of their challenges. Next, we will break down their development ideas and valuable insights.
Project Introduction
In disaster rescue, the most concerning aspect is that rescuers have to navigate through narrow gaps and thick smoke. The A26 team’s “multimodal fusion robot” aims to take on these dangers on behalf of humans – it is not overly complex, but every design is tailored to rescue scenarios.
01）
ROBOT
Core Competence
This robot features a “modular” design: each module resembles a small box (weighing 1kg) that can squeeze through a 10cm wide gap in debris, using binocular cameras to detect obstacles and laser radars to map the environment; if a larger area needs to be covered, several modules can automatically “hold hands” – locking together in 3 seconds with a mechanical structure to form a chain-like structure for wider paths, and even creating a small platform to transport items.
Moreover, it is not afraid of “poor visibility”: it can locate “fire points” using sensors in smoke, sense ground conditions during vibrations, and transmit its location in real-time to rescuers, effectively providing the site with dual “safety eyes”.
02）
ROBOT
Professional Details
The most effort was put into the docking part – to ensure the modules connect securely, the team experimented with magnetic attraction and clips, ultimately opting for a mechanical locking structure that can withstand 10 pounds of weight, ensuring it won’t fall off even in bumpy debris. During previous debugging, they spent several nights optimizing simulations, fearing that it would “fail” during actual use.
In the future, the team hopes to enhance it further: adding “small wings” to allow some robots to fly, achieving “ground gap navigation + aerial reconnaissance”; and switching to more durable materials, aiming to truly assist in earthquake and fire rescue scenarios.
Team Member Introductions
1
Student Xing (Team Leader / Technical Head)
He is the “backbone” of the team, with the core task of “bringing ideas to life”.
From initially proposing the idea of “robots that can disassemble and assemble” to solving the problem of robots “being lazy and not moving” (for example, some robots would freeze when teaming up), to optimizing the docking structure – ensuring that several modules can withstand weight when connected and can dock quickly within 3 seconds, he led the efforts to resolve these issues.
2
Student Lin (Visual Perception and Image Recognition Head)
He is responsible for ensuring the robot can find fire points in smoke and avoid walls while navigating through gaps.
He is in charge of debugging the binocular cameras and laser radars, effectively equipping the robot with “high-definition eyes + a navigation system” – even in low light or smoky conditions, it can clearly see gaps as narrow as 10 centimeters and accurately mark the location of fire points, with an error margin of no more than a fist’s distance.
3
Student Wang (Hardware Driver and Multi-Robot Coordination Head)
The robot’s ability to move and connect is driven by his “commands”.
He writes the code to control the robot’s wheel movements, solving the “stuttering” issue when running; he also designs the communication logic between modules, ensuring that when several robots team up, data can be smoothly transmitted without any “one side moving while the other does not” situation.
4
Student Chen (Business and Market Planning Head)
He does not handle hardware but determines whether the robot can be “actually used”.
He studies how to control costs (for example, selecting cost-effective components), plans how to promote the robot in the future (starting with pilot projects with municipal rescue departments and gradually expanding), and even wrote a business plan to ensure that this student project does not just remain in the competition but has the opportunity to be used in real disaster scenarios.
Q
In terms of technology, is there any design that you consider innovative?
A
It should be the “dynamic weight” design for multi-agent systems and the docking mechanism! During the adjustment of multi-robot collaboration, some robots would “be lazy and not move”; we added an “observation value” that allows the algorithm to adjust parameters automatically without manual changes, resulting in very few issues when 30 robots teamed up; the docking mechanism also took considerable effort, initially trying magnetic attraction which kept failing, and later changing to a “center alignment + peripheral load-bearing” mechanical structure that can withstand 10 pounds of weight, with a docking time of just 3 seconds, making it particularly stable in debris.
Q
When developing rescue robots, safety and stability are crucial. Did you implement any specific designs in this regard?
A
Yes! For instance, the body is made of fire-resistant carbon fiber material, which only deforms at 145℃, making it safe in fire scenarios; additionally, we conducted numerous simulations using ADAMS and Ansys, such as simulating the forces during robot collisions, optimizing vulnerable components to reduce weight by nearly 40% without compromising load capacity; also, the sensors, binocular cameras, and laser radars complement each other’s data – for example, when the camera cannot see clearly in smoke, the radar can fill in the gaps, minimizing the chances of it “running blind”.
Q
Was there anything during the preparation that you now look back on as exhausting but fulfilling?
A
Definitely the “start from scratch” on the third day before the competition! In the first two days, we built a system using Raspberry Pi, but when we tried to add new features, it suddenly crashed, and no adjustments worked. We ultimately decided to delete everything and rebuild. That night, several of us took turns writing code, with Wang writing STM32 drivers until 4 AM, and Lin debugging the camera until dawn. When we finally got it running before sleeping, it felt even better than winning an award – looking back now, even though it was chaotic, no one complained; instead, the busier we got, the more in sync we became.
Q
Did you encounter any unexpected issues during development that disrupted your plans? How did you resolve them?
A
The biggest challenge was buying the radar! Initially, we bought over 100 single-line radars because they were cheap, but there was no documentation for integrating them with the ROS system, making it impossible to fuse data with the camera. With only two days left until the competition, we had to switch to using binocular cameras + IMU for environmental modeling, collecting data during the day and modifying code at night, barely making it work. Later, we learned that radars costing over 500 yuan would provide complete documentation, which was a lesson learned from being “too cheap”; we managed to patch together a temporary solution in the end.
Q
Aside from technology, was there any unexpected growth you experienced during this competition?
A
Collaboration across disciplines! Our team includes students from electronics, mechanics, and even Chen, who studies investment banking. Initially, I thought there would be barriers, like when I (Xing) talked about algorithms, the mechanical students might not understand, but later we found that everyone was “filling in the gaps” – the mechanical students actively looked at the code, the electronics students followed along to create 3D models, and even Chen helped us organize the logic of the technical report. In the end, we realized it wasn’t about “I understand my part, and you understand yours”; it was about everyone working together to turn the “unknowns” into “knowns”. This sense of collaboration is more valuable than any technical improvement.
Q
After this project, do you have plans to make it “more useful”? For example, integrating it with real-world scenarios?
A
Yes! In the short term, we want to create a “modular platform” for the robot, such as separating the perception and control modules so that other teams can use them directly, and even open-sourcing some code for collaborative improvements; in the long term, we hope to collaborate with university laboratories, such as adding a rotor module to allow the robot to fly and run, adapting to outdoor rescue scenarios. We also want to explore partnerships with government emergency projects, as our robot was originally designed for rescue, and being able to use it in real situations would be the most meaningful outcome.
Swipe left to see more images
Conclusion
Having followed the A26 team’s review of their multimodal robot, what is most touching is not how cool the technology is, but their determination to “be serious within limitations” – switching tracks at the last minute before the competition and starting from scratch with the ROS system; using low-cost radars that lacked documentation, they patched together a solution with binocular cameras + IMU; even when multi-robots were “being lazy and not moving”, they did not give up on optimizing the dynamic weight algorithm. Their work may not yet be a “perfect product”, but it embodies the most precious aspects of hardware innovation: the romance of aerospace inspiration brought to life, the pragmatism of rescue scenarios, and the camaraderie of cross-disciplinary partners who stayed up all night without shifting blame.
Now they plan to modularize the technology, open-source desensitized code, and collaborate with university laboratories to move towards “ground and air coordinated rescue”. This persistence from “competition project” to “practical tool” carries more weight than any award. If you are also interested in stories about “using technology to solve real problems”, feel free to keep following – perhaps next time we talk about A26, we will see their robots truly stepping into rescue scenes, navigating through those dangerous narrow gaps and thick smoke on behalf of humans.
END
Let us look forward to the next sharing session!