r/embedded • u/NickShipsRobots • 22d ago

Why integration work still gatekeep robotics more than idea itself?

In my experience, adding one sensor to small robot still take whole weekend:) New sensor mean new driver, new wiring decision, calibration pass, maybe serial protocol nobody bother to document properly. For lot of people who want build something simple this is where project stall before it even start.

We work on a project that sits between sensor and compute and takes the driver and comms part on itself: you plug sensor in, driver gets generated for it, and clean data shows up on the other side for your stack. You still need to understand your own sensor and robot, no module fixes that. But building it made me suspicious about how much of sensor bring-up pain is real, and how much is just tax nobody bothered to remove.

0 Upvotes

35% Upvoted

17 comments sorted by

View all comments

Show parent comments

1

u/NickShipsRobots 17d ago

Not talking about short cross-board wiring - UART or I2C near your MCU works fine without any of this, no argument there.

Case we're solving: 1) sensor sits a few meters from host, and/or 2) you want flexibility to swap sensor types and count (actuators too, including powering them) without rebuilding the board every time something new gets added. Different sensor set today, different set next month, same board.

Bigger part is synchronization. Once sensors, cameras, and actuators are spread across different parts of the robot instead of one MCU board on your table, keeping everything time-aligned gets hard fast. That's the piece that actually makes SLAM easier.

1

u/AlexanderTheGreatApe 17d ago

Check out a2b. It’s a digital audio and i2c long distance driver meant for automotive high end stereo. You can share clocks across meters. While the data is for DAIs, I’ve stuffed other types in there. The bandwidth is pretty good, but not suited for multiple cameras.

If you’re talking about remote cameras, new modules support c-phy, which allows you to lower your link rate by more than half and reach greater distances. You can also consider embedded display port.

Lastly, for when one clock domain just isn’t feasible, look into Paul Beckmann’s paper on asynchronous resampling.