Week Thirteen: Other People's Robots

Two quiet weeks from me. Two very not-quiet weeks from other people. This is the best kind of progress update.

First Community Driver: bb_ufactory

Holden Oullette has built bb_ufactory — a full Beam Bots integration for uFactory xArm cobot arms. This is the first driver built entirely by someone outside the project, and it's not a toy.

What's in the box:

• Joint and Cartesian motion — command individual joints or go straight to end-effector pose (IK solved on-arm)
• Gripper and linear track — G2 gripper position control plus RS485-proxied linear axis
• Force/torque sensing — 6-axis F/T data streamed from 135-byte report frames
• Collision detection — configurable sensitivity with event publishing
• 100Hz ETS control loop — batched joint commands dispatched at high frequency
• Push-based state — joint angles, TCP pose, and torques arrive via the real-time report socket, no polling
• Safety integration — disarm/1 opens a fresh TCP connection to stop the arm even if the GenServer has crashed
• Five arm models — xArm5, xArm6, xArm7, Lite6, and xArm850

The architecture follows the same Controller/Actuator/Sensor pattern as the existing servo drivers, communicating over two TCP connections using uFactory's Modbus-TCP variant: a command socket on port 502 and a real-time report socket on port 30003.

It even ships with a pre-built BB.Ufactory.Robots.XArm6 module so you can get moving with minimal DSL boilerplate. Seriously impressive work, Holden.

bb_policy Gets a Champion

Joel Koch has picked up the bb_policy proposal and is taking a swing at implementation. The goal: let Beam Bots robots execute learned behaviours — think HuggingFace LeRobot models running inference on the BEAM, with policies mapping observations to actions at 20+ Hz.

The proposal defines a BB.Policy behaviour with observe/3, act/2, and action_to_commands/3 callbacks, a Runner GenServer for the control loop, and an ONNX implementation via Ortex as the primary deployment path. The BEAM is genuinely well-suited for this — a crashed policy shouldn't crash a robot, and slow inference shouldn't block sensors. Supervision trees and lightweight processes give you that for free.

Early days, but this is exactly the kind of thing that makes an open-source robotics framework worth building. More as it develops.

Elixir 1.20 Approaches

Elixir 1.20.0-rc.2 dropped on March 4th. The highlights:

• ~10% faster compilation plus a new interpreted mode that scales to your core count
• Type inference across clauses — the compiler finds more bugs and dead code automatically
• Redundant clause detection — warns on dead code paths
• Fewer recompilations when modifying struct definitions (files that only pattern match or update structs no longer recompile)

Phoenix 1.8.5 and LiveView 1.1.26 have already shipped Elixir 1.20 compatibility fixes. Both have been bumped across the Beam Bots ecosystem via Dependabot. Testing BB against the RC is on the short list.

Upstream Releases

A few other notable releases since the last update:

The Kino number input constraints are the most immediately actionable — constraining joint angle inputs to valid ranges with appropriate step sizes is an obvious win for the Livebook widgets.

Dependency Gardening

Dependabot's been busy while I haven't. Across the ecosystem:

Nothing breaking. The garden stays tidy.

What's Next

The servo driver rework is still the priority on my end. But honestly, this fortnight's highlight is other people building things with the framework — that's the whole point. If you're working on something with Beam Bots, come say hello on Discord.

Links

• bb_ufactory on GitHub
• bb_policy proposal
• Elixir 1.20.0-rc.2
• Kino 0.19.0 on Hex
• Livebook 0.19.0
• bb on GitHub
• Proposals repo on GitHub
• Discord