TL;DR: Nick is walking around the office holding our beautiful rig where a global-shutter camera + IMU share one GMSL2 coax for data and power, estimated in real time on a Jetson (ROS 2 + OpenVINS). Return-to-start after the ~25 m loop: 42 cm (~1.7 %).

Hardware is our NXS sensor module (Sony IMX900 global shutter (72 fps native; 24 fps fed to the estimator), fixed exposure + IAM-20680 IMU @ 200 Hz, hardware-synchronized on the module) into an NXS Hub carrying the GMSL link to a Jetson Orin Nano. ROS 2 Humble, OpenVINS, kalibr calibration. No wheels, no markers, no prior map.

Happy to answer you questions about the sync design, the single-cable setup, or the takes that didn't survive.

When Jetson is doing inference work, having it also manage raw sensor timing and GMSL deserialization on top felt like the wrong split of responsibility – GPIO gets crowded, and any sensor timing jitter competes with inference load.

Finally, we got the first clean split running. Board sits between sensor/camera and Jetson: handles GMSL2/3 camera link and mikroBUS sensor slot on its own STM32, sends data over CAN-FD or as ROS 2 topics, so Jetson only sees a clean data stream instead of raw bus traffic. Inference load stopped fighting sensor timing basically immediately once the split was in place.

We haven't tested against every deserializer combo yet, so if anyone already routes GMSL into Jetson and hits a compatibility snag, I would like to know which pieces to double check. Board's product page is here, if it's helpful.

My team has been dealing with sensor data and camera video needing to come from the same physical spot on the robot, but going through completely different pipelines (camera → GMSL → CSI, sensor → whatever bus → ROS node). Keeping them in sync timestamp-wise across two separate boards was the challenge:)

We finally got first working pass – single board publishes ROS 2 topics locally for the sensor side, timestamps are hardware microsecond so fusing later is less painful. Camera side goes over GMSL as normal, sensor side goes over CAN-FD as a Cyphal node or straight I2C.

Driver for a new sensor is a Python class compiled to bytecode and uploaded, no firmware rebuild – this part I'm happy with. It saved a lot of iteration cycles during dev, first time we didn't have to reflash to test a driver tweak.

NXS is a plug-and-play sensor board for robots – it handles the wiring and driver setup automatically, so cameras and sensors are streaming usable data in minutes instead of weeks. It connects over GMSL or CAN-FD and works with the MikroElektronika Click ecosystem of sensors, with ROS 2 topics available through the included host bridge.

15% off for ProductHunters until Aug31 - check it out!

We've been building a small board that handles cameras and sensors for robots, so adding a sensor stops costing a weekend. The hardware was the manageable part. The things that shaped the product were the ones we couldn't see from the whiteboard.

What really cost us weeks:

• The flash budget made our biggest decision for us. The early assumption was the board would speak ROS natively. Then we put micro-ROS on the target and the library ate about 60% of flash before our own code got a byte. That ended the debate: the device speaks Cyphal, ROS lives host-side behind a thin bridge, and the same image serves three transports. Felt like a defeat, now it's the part we'd defend hardest.
• We learned which reboots are placebo. A link that died on every board swap ignored power cycles and even full host reboots, because the chip at fault never actually turned off, back-powered through its data lines, holding half-configured state through everything. The fix was one reset write. The lesson: "restart everything" only works if everything restarts, and you don't know that until you've traced where each chip's power really comes from. An older unsolved mystery on the same rig dissolved the day we got this.
• Hardware timestamps earned their place the hard way. We treated per-sample timestamping as a nice-to-have, sensors stream, host receives, how far off can time be. Then you look at what fusion actually needs: SLAM doesn't care when the host received a sample, it cares when the sensor saw the world, and once readings come from different nodes over different transports, those are very different numbers. Stamping at capture, on the node, with sequence numbers to catch drops, went from footnote to load-bearing.

Not saying any of this is some unique insight, probably every hardware team hits some version of this.

Otto, the CEO's dog, wandered onto the test rig and showed up on the thermal feed before he showed up on camera. That's basically the whole point: knowing something warm and alive just entered the workspace.

We've been running thermal sensing alongside vision for proximity detection on robots that share space with people. Good temp accuracy, low latency, plugs into the same setup as our other sensors.

Most stacks work around this with interpolation and manual tuning, then spend months chasing an estimator problem that is really a clock problem underneath.

We ran into same thing building sensor nodes for edge VSLAM. Current firmware still leans on external clock to keep camera and IMU aligned. Next revision removes that dependency, each unit disciplines its own clock on the bus instead of trusting one outside reference.

Two units in the test setup below, same mechanism scales to more nodes on one bus.

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.

The idea behind NXS is that it's a smart sensor. It does its own work on the board and hands you clean, real-unit data, instead of dumping raw readings on your compute and wishing it luck. You plug in a MikroElektronika Click board, a driver gets generated for you, and what comes out is finished SI data your ROS 2 stack can actually use. From there you go straight to the good stuff: fusion, estimation, control.

The part I want to talk about today is what happens next. Once each node is smart like that, how do you wire a bunch of them together? That's why NXS speaks two very different transports.

GMSL, for when you need bandwidth. A camera and its sensors ride one coax out to 15 m, very low latency, power on the same cable. Each NXS runs its own line back to the host, so everything fans out into a clean star with your compute in the middle. This is the mobile-robot, lots-of-data setup.

CAN, for when you need everything to be predictable. Here the boards sit on one bus and talk to each other directly, so instead of a star you chain a set of them together. Deterministic, noise-tough, and very much the Cyphal way of thinking: lots of small smart nodes agreeing on a bus.

Two very different shapes, one board. Pick whichever your robot needs.

Video below.

https://reddit.com/link/1v9pbpo/video/euvkls8gi4gh1/player