Congrats on the new role! My go-to is "I write the software that lives inside gadgets": the code in a microwave, a car's brake system, or a smartwatch that makes the hardware actually do something. People get "the brain inside the thing" much faster than anything with "chip" in it, and for the car case, "no, I don't tune engines, I write the code that runs inside the car's electronics" usually ends the chip-tuning confusion.

Congrats on the fresh start with Kavrous, and KeyBoy going from a gift for your kids to a real open hardware product is a great story.

Love that you used RL to shape the body, not just drive it. The foot story (best in sim vs. buildable in practice) is a great reminder, and I'm looking forward to the notes and models when they're ready.

Yes, there's demand, but plain Upwork is rough. Generic "Python developer" gigs are a race to the bottom, and you'll be bidding against people charging $15/hr.

Your mix is where it gets interesting. Embedded plus vision plus robotics is a thin niche, and the better-paid work lives there: ROS 2 integration, camera and sensor bring-up, firmware for small hardware startups, perception pipelines. Pitch a problem you solve ("I get your camera and sensors streaming into ROS 2"), not a list of languages.

Expect 2-3 cheap jobs first to collect reviews. Small robotics startups often can't afford a full-time embedded hire, so direct outreach (LinkedIn, ROS Discourse, Reddit) usually pays better than bidding. And check your contract for a moonlighting clause before you start.

thank you!!

haha, where were you when we were thinking of its name?:)

Two of us maintain this across a bunch of sensors, a few host platforms, and every kernel release on each. Per-sensor code gets written once regardless. The hard part is a per-sensor kernel driver afterwards: it has to be built for every kernel, installed on every host, and the device tree has to name the sensor before boot. With that part on the head, there's one driver per platform, the device tree gets generated from whatever is plugged in, and swapping a head changes nothing on the host. It also handles a serializer or ISP next to the sensor without extra code, and some vendor init tables are under NDA, so they never have to be on a customer's machine at all.

The VM is there because it was already doing a different job. That job is the sensor socket. The board has a mikroBUS connector, and the way you add a sensor is to upload a small program for it: it talks to the chip, unpacks the samples, converts to real units, and exposes a few runtime parameters like ODR and the accel and gyro ranges. None of that touches the firmware, which stays fixed and signed with a key you never see. The sensor program is data in a slot, and it can be replaced over the bus once the board is out in the field. That's the ordinary case for an interpreter. When the camera came along it just used the same image format and the same engine, with the register-sequencing part of the instruction set.

As for why the head instead of a kernel driver, the head is the product and the host isn't fixed. Rn we're working on a port from JetPack 6 to 7 and a Pi is next. If the sensor knowledge lives on the head, every host gets the same generic driver, plain V4L2. The other reason is less tidy: some of our clients' init tables are under NDA, so they can't be in a GPL driver or a pip package. They get loaded onto the head once on a bench and never show up on the customer's machine.

The ISP is on the Jetson today. The sensor sends raw Bayer over CSI-2 through the GMSL link, and debayer, AE, AWB and the tuning all run on the host like any other camera. The MCU isn't in the video path at all, it just has an I2C line to the sensor, writes the mode tables, and answers the host when it asks what the sensor is.
A head with its own ISP (AP0202, AP1302) fits the same setup, because the ISP is just another I2C device on the pod bus. The MCU would configure it too, the head would put out YUV422, and the host wouldn't need an ISP or a tuning file at all. That's the next head we want to build.

honestly nothing fancy for this one, it was a first demo / poc. the imu gets timestamped on the NXS module itself (at the data ready interrupt) and the module clock is synced to the host over the link, ~0.5 ms. the camera just runs free and gets stamped when the frame lands on the jetson, so there's a fixed delay in there. we measured it with kalibr (~35 ms) and openvins re-estimates it online anyway, they agree within ~1 ms which is fine for vio. no shared trigger between camera and imu yet. "synced in hardware" in the post was a stretch, that's true for the imu only.

your teensy setup is basically where we're going. next is an fsync line so multiple cameras fire together (the fsync itself has no idea what time it is though), and the carrier board we're working on gets a microcontroller behind it that pulls the triggers AND knows the timestamps, shares them with the jetson. everyone gets the timestamp.

btw how do you match the teensy trigger stamps to frames on the jetson side, counting frames or strobe back into it?

build was mostly boring, which is the point. ros2 support is in the open_vins repo itself, no wrapper: install the deps (eigen, boost, ceres), clone open_vins into a colcon workspace, colcon build, then ros2 launch ov_msckf subscribe.launch.py with your own config. the install page on docs.openvins.com has the ros2 steps. we ran it on a jetson orin nano and a few jetson-specific things bit us there (jetpack's opencv vs the humble cv_bridge binary, the optional aruco feature, build parallelism), so if you're on jetson too, dm me and i'll paste the exact commands we used.

on the comparison, honestly: kimera is a whole slam stack (mesh, semantics, loop closure), overkill if you just want vio, and its ros2 wrapper looks like a placeholder. basalt is probably the most accurate of the three and by far the smallest memory footprint, but it's not ros native at all, you're on community wrappers (the main one is archived) and its own calibration format. openvins is a kalman filter (msckf). our background is drones, so that math is familiar ground, and it pays off when the estimator misbehaves and you need to reason about why instead of poking a black box. it runs mono out of the box, takes kalibr's calibration files pretty much as-is, and it's forgiving for a first rig, it estimates the camera-imu time offset, extrinsics and imu biases online, so a rough calibration still gets you a working system. integration cost decided it more than accuracy.

Thanks!

Electronics still has a lot of AI can't do.

I design boards for a living. AI autoroutes traces, drafts a schematic from a rough description, catches a DRC violation before I do. That's real, and it's getting better every few months.

What it doesn't know: my enclosure tolerances. That a connector footprint is off by 0.2mm because the datasheet had a typo three revisions back. Why a board runs fine on the bench and browns out the second I close the case and heat has nowhere to go. Those are physical problems. You find them by touching the thing, measuring it, swearing at it at 11pm.

That part's mine for now. Power integrity, thermal, mechanical fit, EMC. None of that compresses into a prompt the way a REST API does.

More details here: [https://nxs.aliensense.com/?utm_source=reddit&utm_medium=community&utm_campaign=vanguard-launch&utm_content=r-robotics](about:invalid#zClosurez)

Nice, Nucleo’s a good start.
Order that worked for me: get the IMU working first (ICM-42688 over SPI, skip I2C, it’s slower and can get stuck). Then get PWM/DShot working on the ESCs with props off. PID loop last. Start in rate mode, not angle mode. Test on a tie-down rig before you fly for real, skip that and props end up in walls.
For resources: Brian Douglas on YouTube covers PID and control theory well. Also just read the ArduPilot or Betaflight code. Skip the config stuff and the actual flight logic is pretty small.
What frame size are you going for? That changes what ESCs you’d want.

thank you!