Three bugs that changed how our sensor board talks to ROS 2
📌 概要
团队开发连接摄像头与传感器的传感器板（CAN-FD + GMSL2），开发中三个bug改变了设计：micro-ROS占用60%闪存，迫使改用Cyphal协议、ROS由主机侧桥接；另有热插拔后链路失效等通信问题影响架构决策。
⚡ 关键要点
- ▸micro-ROS在写入业务代码前就吃掉60%闪存，放弃板载直连ROS
- ▸固件改用Cyphal，ROS在主机侧通过薄桥接层对接，一版固件支持三种传输
- ▸换板后链路假死、重启无效等bug暴露总线设计缺陷
- ▸硬件通过CAN-FD与GMSL2连接传感器与机器人计算单元
We’re working on a board that connects cameras and sensors to a robot’s compute over CAN-FD and GMSL2. Three things came up during development that changed the design more than anything we planned upfront.
The flash budget made the decision for us.
We started assuming the board would speak ROS directly. Put micro-ROS on the chip to test it, and it ate 60% of flash before we’d written any of our own code.
That settled it. The device speaks Cyphal now. ROS runs host-side behind a thin bridge, and one firmware image serves three transports instead of one.
One reboot didn’t actually reboot anything.
A link kept dying every time we swapped a board. Power cycles didn’t fix it. Full host reboots didn’t fix it either.
Turned out one chip never fully powered off. It was getting backfed through its own data lines and holding old state through every reset we tried. The fix was a single reset write, once we found where the power was actually coming from.
Also explained an older bug on the same rig we’d never tracked down. Same root cause.
Timestamps mattered more than we assumed.
We treated per-sample timestamps as optional at first. Sensor sends data, host receives it, how far off could the timing really be.
Turns out it matters a lot once you’re fusing readings from different nodes on different transports. SLAM cares when the sensor captured the reading, not when the host got it. Those two numbers aren’t close.
Now every sample is stamped at capture, on the node, with a sequence number so drops are visible.
Wrote this up mostly for our own record and I guess other people building sensor nodes run into some version of the same three things.
1 post - 1 participant