July 2026: Show Your Working
The maths core moves to Nx defn with analytical Jacobians, both IK solvers ride along, the balance bot starts rolling its wheels, and your robot now renders in 3D inside a terminal.
Last month the robot learned which way is up. This month it learned to show its working.
The thread running through June is the maths. bb's entire transform and kinematics core moved to Nx defn, which means analytical Jacobians instead of finite-difference guesswork — and both inverse-kinematics solvers immediately cashed in. Meanwhile the balance bot stopped being a stack of parts and started turning its wheels, and over in the terminal, Mauricio got an entire robot rendering in 3D without a browser in sight.
The Maths Core Goes defn
The headline release is bb 0.22.0: forward kinematics, all-link transforms, and Jacobians are now expressed as Nx defn (#147, #161).
That sounds like plumbing, and most of it is. But it buys something concrete: an analytical Jacobian. Previously, working out how a small change in each joint angle moves the end effector meant nudging every joint a tiny bit and measuring — finite differences. It works, but it's slow and a bit approximate, like estimating a derivative by squinting at the graph. With the kinematics defined as defn, the Jacobian is computed properly, and the maths shows its working.
The payoff landed the same week, in the solvers:
bb_ik_dls0.4.1 now usesbb's analytical Jacobian instead of finite differences (#52). Faster, more accurate, fewer iterations to converge.bb_ik_fabrik0.4.1 re-expressed its position-and-orientation solve as composabledefns (#60).
This is the satellite model working exactly as intended: core gets a better primitive, and the packages that depend on it get faster for free.
The Balance Bot Starts Rolling
The balance bot for the Goatmire workshop has gone from "box of components" to "thing that moves." It's now pairing the orientation estimation from last month with actual wheel motion via DRV8837 motor drivers. Knowing which way is up is only useful if you can do something about it, and now it can.
On the hardware front, Gus Workman has all but finished the final board turn for the Nerves Starter Kit and is posting me some boards this month — so I'll soon be testing on the real target rather than a breadboard approximation of it. He also shipped the other half of that story: nerves_system_trellis v0.4.0 (June 26) adds official Nerves Starter Kit support, U-Boot console on the NSK pins and all. The board the workshop runs on now has a released Nerves system underneath it.
Goatmire is three months out and prep on my talk is quietly ticking along. I'm keeping the details under wraps for now — partly to not spoil the surprises, partly because I'm still pinning down the scope. The balance bot, meanwhile, stays the star of the workshop.
Your Robot, in 3D, in a Terminal
Mauricio Cassola has been busy, and the result is genuinely fun: a live 3D view of your robot, rendered in the terminal.
His ex_ratatui shipped 0.10 and 0.11 with a new Viewport3D widget — a proper scene graph, mesh primitives, and pixel-graphics rendering over Kitty and Sixel (with a braille fallback for terminals that can't do pixels). Then bb_tui 0.2 and 0.3 wired it up: a Visualization tab that builds a 3D scene from your robot's URDF topology via forward kinematics, with camera controls, and surfaces battery, hardware-error and estimator telemetry alongside it.
So if you SSH into a headless robot, you can now watch a 3D model of it move in your terminal. No browser, no X server, just ANSI escape codes doing far more than they were ever meant to. Mauricio shared a clip, and honestly it has to be seen to be believed:
I love it.
Safety Got Honest
A quieter but important theme: the servo drivers' disarm paths learned to stop lying.
Disarming a robot — cutting torque so it goes limp and safe — used to be fire-and-forget. You'd ask the servos to disable torque and assume they did. The problem with assuming, in a safety system, is that a dead controller could happily report "all disarmed!" while the motors stayed energised. Not ideal when "disarmed" is the word standing between a robot arm and your fingers.
So across bb_servo_feetech 0.3.2, bb_servo_pca9685 0.6.2 and bb_servo_robotis 0.3.2, disarm now confirms torque is actually disabled and reports failure honestly instead of false success (#51, #57). The Feetech and Robotis drivers also got a 0.3.3 that fetches the servo control table lazily, so the parameter bridge survives controller startup ordering instead of racing it (#61).
Safety All the Way Down to the Chip
Speaking of safety, Edgar Gomes de Araujo — who you'll meet again in a moment — has been building bb_mcuhub, and it takes the let-it-crash safety story somewhere the framework hasn't gone before: onto the microcontroller itself.
The problem it solves: your Elixir brain runs on a Raspberry Pi, but the chips actually reading sensors and driving motors are microcontrollers hanging off the other end of a wire. bb_mcuhub is that wire and its safety layer — a drift-checked binary link, plus a C/ESP32 firmware kit. Its one idea is the hub: a single microcontroller that reads sensors, drives actuators, and forwards messages for its children, so hubs nest into a tree of any depth over a single UART.
The clever part is where the safety lives. Each actuator boots born-disarmed and won't move until it sees a fresh command, and an on-chip dead-man means a yanked cable or a crashed host stops the motors by itself — the host doesn't have to do anything, because it might be the thing that died. That's the same instinct as force-disarm living in the supervision tree, pushed one layer further down than Elixir can reach.
It already drives a real two-wheel self-balancing bot (segby_v1) on ESP32 hardware — and, handily for the rest of us, you can run the whole host stack with zero hardware, or drive the bot in a MuJoCo physics simulation with a 3D viewer. No chassis required.
Cancelling Without Crashing
The other follow-on from the estimation work is that continuous commands now cancel cleanly.
A command that runs forever — hold this position, jog this joint — needs a stop button. Previously, stopping one looked like a crash to the supervisor, which dutifully logged it as an error. Honest, but noisy: cancelling a command you meant to cancel isn't a fault.
bb 0.22.1 now stops commands gracefully so cancellation isn't logged as a crash (#167), bb_reactor 0.2.4 handles the graceful {:shutdown, reason} exit in saga steps (#54), and both bb_kino and bb_liveview gained actual cancel controls for continuous commands.
Keeping Up With the Firehose
An IMU streaming orientation updates is a lot of traffic, and last month's estimation stack found the limits of the dashboards. Both UIs learned to cope:
bb_kino(0.3.5–0.3.7) throttles event-stream rendering and now accumulates joint updates before redrawing the 3D view and sliders, rather than redrawing per message.bb_liveview(0.2.8–0.2.9) throttles dashboard rendering under high-rate sensor traffic and pushes the full joint pose to the 3D view each frame instead of one joint at a time.
Net effect: the dashboards stay smooth even when a sensor is shouting.
Coming Soon: Learned Policies
A brief teaser. Work has started on bb_policy (proposal 0002) — a package for running learned, neural-network robot behaviours: train a policy elsewhere, export it to ONNX, and run inference on the BEAM in the same runtime as control, with full safety integration. It's an early scaffold and not on Hex yet, with much of the groundwork — you guessed it — coming from Edgar, who has evidently decided one substantial new package a month isn't enough. More once it's real enough to demo.
Housekeeping
- Elixir 1.20 has landed and the ecosystem has moved onto it.
feetech0.2.3 pinned its bitstring size variables for the new compiler, and the rest of the packages followed. feetech0.2.4 corrected the STS3215 speed register unit to steps/second (#45) — the kind of fix you only find by watching a servo move at the wrong speed.bb0.20.3 added a generatedrobot_opts/0helper for new robots, and the sensor and servo packages all picked it up to slim down their child specs.
On the Bench
I've ordered the parts for a second SO-101 arm. Two arms opens the door to teleoperation — driving one arm by moving another — and to recording demonstrations for training, which is exactly the kind of data bb_policy will want to eat. One thing tends to lead to another around here.
Come Say Hello
One more thing: Beam Bots now has its own section on the Elixir Forum. Who'll be the first to post? (No pressure.)
I'm looking forward to meeting some of you at Goatmire in September and sharing my love of all things Elixir, Nerves and robotics. I'll also be sticking around for the Ash Summit on 3 October in Varberg, right after the main Goatmire conference — the CFP is open, so if you've got a talk in you, submit it. And if Sweden isn't on the cards this year, you'll find me on the Discord or the forum.