Week Eleven: The Quiet Fortnight

2026-02-23T00:00:00+00:00

No progress post last week — sometimes the interesting work is the kind that doesn't ship yet. Here's what's been happening across the last fortnight.

Beam Bots at Nerves Meetup EU</h2>
The highlight of the fortnight came from someone else entirely. Gus Workman presented "An early peek at the official Nerves hardware starter kit"</a> at the Nerves Meetup EU</a> on February 11th. The talk included a shoutout to Beam Bots and a mention of our plans to build a balance bot with the starter kit — I'm excited to get my hands on one. Thanks, Gus!

Servo Driver Architecture Rework (In Progress)</h2>
The SO-101 demo video that was "coming soon" two weeks ago is still coming. The delay is deliberate: I'm reworking the driver architecture for both the Feetech and Robotis servo integrations to make moves smoother and avoid collisions on their respective serial links.
This work shouldn't require changes to `bb</code> core, but it will change how the servo driver packages coordinate serial bus access. The current approach works fine for single commands, but when you're running coordinated multi-servo moves at speed, you need tighter control over who's talking on the wire and when.`
`More on this when there's code to show.`
`Nx 0.11.0</h2>`The Nx 0.11.0</a> release landed on February 19th and has already been bumped in bb</code> core (#58</a>). Highlights include FP8 E4M3FN support, Nx.Mesh</code> and Nx.Defn.shard_jit/3</code> for multi-device execution, Nx.runtime_call/3</code>, and a fix for Nx.sort/2</code> gradients. No breaking changes — just a clean upgrade. Dependency Gardening</h2> Dependabot kept busy while I didn't. Across the ecosystem: Package</th> Bumped in</th> Change</th></tr></thead> bb</td> 0.15.0 → 0.15.1</td> bb_servo_feetech, bb_servo_pca9685, bb_servo_robotis, bb_ik_dls, bb_ik_fabrik, bb_kino, bb_liveview, bb_reactor</td></tr> phoenix_live_view</td> 1.1.22 → 1.1.24</td> bb_liveview, bb_example_wx200</td></tr> feetech</td> 0.2.1 → 0.2.2</td> bb_servo_feetech</td></tr> bb_servo_feetech</td> 0.2.0 → 0.2.1</td> bb_example_so101</td></tr> bb_reactor</td> 0.2.0 → 0.2.1</td> bb_example_so101, bb_example_wx200</td></tr> bb_liveview</td> 0.2.3 → 0.2.4</td> bb_example_wx200</td></tr> </tbody></table> Nothing breaking — the ecosystem stays tidy even when the maintainer is elbow-deep in serial protocols. What's Next</h2> The servo driver rework is the priority. Once that's solid, the SO-101 demo video can finally happen. For real this time. Probably. Links</h2> Gus's Nerves Starter Kit talk</a></li> Nerves Meetup EU</a></li> Nx 0.11.0 on Hex</a></li> bb on GitHub</a></li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Week Nine: No Hardware Required 2026-02-10T00:00:00+00:00 This one's a day late. I'd hoped to ship an exciting SO-101 demo video yesterday, but the universe had other plans. Still, the code is out there and that's what matters. The SO-101 Example Is Live</h2> The big news this week: bb_example_so101</a> is now on GitHub. It's a complete Phoenix application demonstrating the Beam Bots framework with a SO-101 robot arm</a> - the open-source 6-DOF arm from TheRobotStudio that uses Feetech STS3215 servos. If you've been following along and wondering "but what does a real Beam Bots application actually look like?" - this is your answer. What's included: Robot definition using the BB DSL - all six joints plus gripper, with proper kinematic chain from the official URDF</li> Web dashboard with real-time 3D visualisation via bb_liveview</code></li> Servo setup wizard (mix so101.setup_servos</code>) - interactive tool for assigning unique IDs to each servo (they all ship as ID 1, because of course they do)</li> Calibration tool (mix so101.calibrate</code>) - disables torque, prompts you to move each joint through its full range, writes EEPROM offsets so centre = 0 radians</li> Custom commands - home, demo circle, move to pose, arm/disarm</li> </ul> And the best part: you don't need the hardware. Set the SIMULATE</code> environment variable to anything non-empty and the whole thing runs in simulation mode with the 3D visualiser. Want to poke around a robotics framework without spending money on servos? Now you can. There'll be a separate blog post coming soon with a proper getting-started guide and links to kit sources. For now, go have a look. Two Bugs Walk Into a Serial Port</h2> Getting the SO-101 working on real hardware surfaced two bugs that were hiding in the Feetech stack. Both are the sort of thing that only shows up when you're actually talking to six servos at once on a real wire. The Buffer Threading Bug (feetech v0.2.2)</h3> At 1Mbaud, all six servo responses to a sync_read</code> arrive in about 1.2 milliseconds. That's faster than individual UART reads can consume them, so multiple responses pile up in the receive buffer. The old code parsed one response and threw away the remaining bytes. The next read would then fail or return garbage. The fix threads the remaining buffer from each parsed response into the next read call. Not glamorous, but essential for reliable multi-servo communication at high baud rates. The Stale Goal Impulse (bb_servo_feetech v0.2.1)</h3> Here's a fun one. Feetech servos auto-enable torque the moment you write to goal_position</code> - even if you haven't explicitly enabled torque yet. So if a servo remembers a goal position from a previous session and you write a new goal during initialisation, it lurches to whatever position it was told last time. When "last time" was the other side of the workspace, that lurch is... dramatic. The fix uses reg_write</code> to buffer the goal position for each servo (which doesn't trigger the auto-torque behaviour), then fires a single action</code> command to apply all goals simultaneously. Torque stays off until every servo has a sane goal. No more surprise gymnastics on startup. Both bugs were hardware-tested on the SO-101 with all six servos. The arm now powers up calmly, which is how robot arms should behave. Other Releases</h2> Package</th> Version</th> What changed</th></tr></thead> bb</td> v0.15.1</a></td> Docs fix: correct BB.Message.Sensor.IMU</code> references to Imu</code></td></tr> feetech</td> v0.2.2</a></td> Buffer threading fix for sync_read at high baud rates</td></tr> bb_servo_feetech</td> v0.2.1</a></td> Stale-goal torque impulse prevention</td></tr> bb_servo_pigpio</td> v0.5.0</a></td> Migrate to structured error system</td></tr> </tbody></table> That's every servo driver now on structured errors. Consistency: achieved. Dependency Gardening</h2> Dependabot had a busy week. Across the ecosystem: credo to 1.7.16 (Elixir 1.20.0-rc.1 compatibility, new UnusedMapOperation</code> and UnusedOperation</code> checks), ex_doc to 0.40.1 (now generates llms.txt</code> - how very zeitgeist), igniter to 0.7.2, mimic to 2.3.0, phoenix_live_view to 1.1.22, and bandit to 1.10.2. Nothing breaking, just keeping the garden tidy. What's Next</h2> The SO-101 getting-started blog post is the immediate priority. I want to have clear kit lists, assembly notes, and a walkthrough from unboxing to "arm moves when you tell it to." After that, there's the demo video that was supposed to ship yesterday. Soon. For real this time. Links</h2> bb_example_so101 on GitHub</a></li> bb on Hex</a> (v0.15.1)</li> feetech on Hex</a> (v0.2.2)</li> bb_servo_feetech on Hex</a> (v0.2.1)</li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Week Eight: New Digs 2026-02-02T00:00:00+00:00 A quieter week on the code front, but we have news. We've Moved</h2> The Nerves community has launched their own Discord server, separate from the Elixir Discord. It's a good move - the embedded Elixir world has grown enough to warrant its own space, and the Nerves folks have always been wonderfully welcoming. Beam Bots is moving with them. If you've been following along on the Elixir Discord, you'll find us at the new address: discord.gg/QSag7Vuc4N</a> Same channel name (#beam-bots</code>), same people, new server. Come say hello. Why Follow Nerves?</h2> If you're wondering why a robotics project would follow an embedded systems community: Beam Bots doesn't have to run on Nerves, but it likes to. The framework works anywhere Elixir runs, but it's designed with embedded hardware in mind - Raspberry Pis, BeagleBones, and whatever boards the future brings. Nerves makes deploying to those targets painless. The Nerves team has been incredibly supportive since the project started. Frank Hunleth donated the WidowX-200 that kicked off real hardware testing. Gus Workman from Protolux is collaborating on the balance bot. The overlap between "people interested in Elixir on embedded hardware" and "people interested in Elixir controlling robots" is basically a circle. So when the Nerves community moves, we move with them. Links</h2> bb on Hex</a> (v0.15.0)</li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Week Seven: Jido Enter Stage Left 2026-01-26T00:00:00+00:00 Some weeks you ship two feature releases and reorganise all the documentation. Other weeks you... don't. This is one of those weeks. But "no releases" doesn't mean "nothing happening." Proposal: bb_jido</h2> The most interesting development this week is Proposal 0009: bb_jido</a> - integrating the Jido</a> autonomous agent framework with Beam Bots. If you read the Beyond Behaviour Trees</a> post, you know we're using sagas (via bb_reactor</code>) for structured workflows. Sagas are excellent when you know the sequence of steps upfront: pick up block, move to destination, place block. But what about when you don't? "Pick up the red block" sounds simple until you realise the robot needs to: Figure out which block is red</li> Decide how to approach it</li> Handle the case where another robot got there first</li> Adapt when the human moves it while you're reaching</li> </ul> This is where autonomous agents shine. Jido sits above our saga layer: ┌─────────────────────────────────────────────────┐ │ Jido Agent │ │ - Observes world state via BB sensors │ │ - Selects strategy based on context │ │ - Invokes workflows or commands │ ├─────────────────────────────────────────────────┤ │ bb_reactor Workflows │ │ - Structured sequences with compensation │ ├─────────────────────────────────────────────────┤ │ BB Commands │ │ - Direct robot control │ └─────────────────────────────────────────────────┘</code></pre> The agent decides what to do. The saga decides how to do it. The commands make it happen. Jido is event-driven (no polling loops), keeps agent logic pure (effects as directives, not side effects), and the core has zero LLM code - AI integration is optional via jido_ai</code>. It fits our philosophy nicely. The proposal is open for discussion. If you have thoughts on how goal-directed robot behaviour should work, now's the time to share them. Proposals Still Open</h2> Two proposals from last week are still under discussion: Proposal 0007: Usage Rules</a> - LLM-friendly documentation standards</li> Proposal 0008: bb_mavlink</a> - MAVLink protocol for drones</li> </ul> What's Next</h2> The SO-101 getting-started experience is still the priority. Once that's smooth, I can create videos that don't require expensive hardware. The balance bot collaboration with Gus is progressing, but it's waiting on the Nerves Starter Kit design. And bb_jido? That depends on how the proposal discussion goes. Links</h2> bb on Hex</a> (v0.15.0)</li> Jido on Hex</a></li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Week Six: Balance Bots and Better State Machines 2026-01-19T00:00:00+00:00 Holiday's over. Back to the day job. But somehow I still managed to ship two feature releases, a bug fix, and sort out the documentation. Not bad for a short week. Also, happy Wellington Anniversary Day to me. Nothing says "public holiday" like writing release notes. Nerves Starter Kit Balance Bot</h2> The most exciting news this week isn't a package release - it's a collaboration. I've started working with Gus Workman</a> from the Nerves Core Team. He's the founder of Protolux</a> and is finalising the design for the Nerves Starter Kit - think of it as a spiritual successor to those name tag boards from last year's Goatmire/NervesConfEU, but with a larger e-ink display, a much smaller board, and more IO broken out for tinkering. We're collaborating on a simple add-on: two gear motors and an 18650 battery holder to convert the Starter Kit into a balance bot. The idea is to create something approachable for workshops and getting-started videos. A balance bot is just complex enough to be interesting (sensor fusion! PID control! falling over!) without being overwhelming. More details as the hardware design solidifies. But if you've ever wanted to see Elixir keeping a robot upright, this should be fun. Command Categories and Concurrency</h2> BB v0.15.0 introduces command categories with configurable concurrency limits. The problem: robots often have independent subsystems. Your gripper shouldn't have to wait for the arm to finish moving. But the old system ran one command at a time, full stop. The solution: define categories inside your commands</code> block, each with its own concurrency limit. commands do category :motion do doc "Physical movement commands" concurrency_limit 1 # Only one motion at a time end category :sensing do doc "Sensor and data collection" concurrency_limit 2 # Can run two sensing ops concurrently end command :move_to do handler MoveCommand category :motion cancel [:motion] # New motion cancels previous motion end command :read_sensor do handler ReadSensorCommand category :sensing end end</code></pre> The rules are straightforward: Different categories = parallel: A :motion</code> command and a :sensing</code> command run simultaneously</li> Same category = limited by concurrency_limit: If you try to run a second :motion</code> command (limit 1), it either cancels the first (if cancel: [:motion]</code>) or fails with a "category full" error</li> No category = uses :default</code>: The implicit default category has limit 1, preserving backwards compatibility</li> </ul> This is groundwork for mobile manipulators, multi-arm systems, data collection robots - anything where "one thing at a time" doesn't cut it. Mimic Sensor for Linked Joints</h2> BB v0.14.0 adds BB.Sensor.Mimic</code> for mechanically-linked joints. Some robot designs have joints that are physically connected - when one moves, the other follows. The WidowX-200's gripper works this way: two prismatic fingers driven by a single servo. You could model them as separate actuators and hope they stay in sync, but that's asking for trouble. BB.Sensor.Mimic</code> subscribes to one joint's position and publishes matching JointState</code> messages for the mirrored joint. The kinematic chain stays accurate, and you don't have to pretend the linkage doesn't exist. sensor :right_finger, {BB.Sensor.Mimic, source: :left_finger, multiplier: -1.0 # Mirror direction }</code></pre> Simple, but necessary. Feetech Sign-Magnitude Fix</h2> Remember when I said the Feetech driver was buggy? One bug down. feetech v0.2.1 fixes sign-magnitude encoding for signed registers. Turns out Feetech servos don't use two's complement for negative values - they use a sign bit in the high byte. So when you asked for a negative velocity, you got... not what you expected. The SO-101 now moves in the directions I tell it to. Progress. Documentation Gardening</h2> All three packages (bb, bb_kino, bb_liveview) got a documentation tidy-up this week. We've always used the Diataxis framework</a> - tutorials, how-to guides, reference, explanation - but when you only have a handful of pages it doesn't matter much where things go. As the framework grows, so does the documentation, and keeping it organised becomes like gardening: constant small efforts to stop the weeds taking over. This round added new tutorials, filled in some reference gaps, and shuffled things into their proper categories. Still plenty of gaps to fill, but at least the beds are tidy. Proposals Update</h2> The six proposals from last week are now merged into the proposals repo</a> - bb_teleop, bb_policy, bb_dataset, bb_mcp, bb_tui, and bb_motion_planning are all accepted designs waiting for implementation. Two new proposals are open for discussion: Proposal 0007: Usage Rules</a> (new) - A standard way to include LLM-friendly documentation in packages. If you've used usage-rules.md</code> files before, this formalises the approach. Proposal 0008: bb_mavlink</a> (new) - MAVLink protocol integration for drones and other autonomous vehicles. This one's ambitious, but MAVLink is the lingua franca of the drone world. SO-101 Status</h2> The arm works. The example code exists. But I'm not ready to encourage people to build one just yet. Feetech servos have some quirks. For instance, they have a tendency to enable torque the moment you write a new configuration. That's... not ideal when you're trying to set limits before powering up. I want to make sure the getting-started experience is smooth before pointing people at it. Soon. All The Releases</h2> Since January 12th: Package</th> Version</th> What changed</th></tr></thead> bb</td> v0.15.0</a></td> Command categories with concurrency limits</td></tr> bb</td> v0.14.0</a></td> BB.Sensor.Mimic</code> for mechanically-linked joints</td></tr> bb</td> v0.13.2</a></td> Bridge name uniqueness enforcement in DSL verifier</td></tr> feetech</td> v0.2.1</a></td> Sign-magnitude encoding fix for signed registers</td></tr> bb_kino</td> v0.3.3</a></td> Documentation improvements</td></tr> bb_liveview</td> v0.2.4</a></td> Documentation improvements</td></tr> </tbody></table> What's Next</h2> Getting the SO-101 experience polished remains the priority. Once that's solid, I can start making videos that don't require a $2000 robot arm. The balance bot collaboration with Gus is exciting, but it's hardware-dependent - we need the Starter Kit design locked down first. Links</h2> bb on Hex</a> (v0.15.0)</li> feetech on Hex</a> (v0.2.1)</li> Protolux</a></li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Week Five: Tasks Get Orchestrated, Roadmaps Get Transparent 2026-01-12T00:00:00+00:00 Four new repositories in one week. One of them warranted its own blog post. Not bad for the first full work week of the year. Turns out the secret to productivity is being on holiday with nothing to do but tinker with robots. Amazing what happens when nobody expects you to be anywhere. BB Reactor: Task Orchestration Done Properly</h2> The headline release this week is bb_reactor</a>, which brings Reactor</a> saga orchestration to Beam Bots. I wrote a whole separate post</a> about why we went this direction instead of behaviour trees, but the short version: Compensation and rollback - When a step fails, earlier steps can undo their work. Your robot doesn't get left in a weird state.</li> Dependency-driven concurrency - Independent steps run in parallel automatically. No explicit parallel nodes needed.</li> Event-driven, not poll-driven - Steps wait for actual messages, not tick cycles. Much better for embedded systems.</li> Safety integration - E-stop while a reactor is running? It halts immediately. No more steps execute.</li> </ul> defmodule PickAndPlace do use Reactor, extensions: [BB.Reactor] wait_for_state :ready, states: [:idle] command :move_to_pick do command :move_to_pose argument :target, input(:pick_pose) wait_for :ready compensate :return_home # If downstream fails, go home end command :grip do command :close_gripper wait_for :move_to_pick end wait_for_event :grip_confirmed do path [:sensor, :force_torque] filter &(&1.payload.force > 5.0) wait_for :grip end # ... continue to place position end</code></pre> If the grip fails, the reactor automatically runs :return_home</code> to compensate. Behaviour trees don't give you that for free. The Proposals Repo</h2> What's next for Beam Bots? Now you can find out without reading my mind. The new proposals repository</a> is a lightweight RFC system. Want to know what features are planned? Check the PRs. Want to propose something? Open a PR using the template. Currently open for discussion: bb_teleop - Teleoperation framework (spacemouse, gamepad input)</li> bb_policy - Behaviour cloning and policy learning</li> bb_dataset - Recording and replaying robot trajectories</li> bb_mcp - Model Context Protocol integration (yes, AI-assisted robotics)</li> bb_tui - Terminal UI for robot control</li> bb_motion_planning - Path planning with obstacle avoidance</li> </ul> No committees. No final comment periods. Just drafts, discussion, and implementation. If something in there looks interesting and you want to help build it, say hi in Discord. SO-101 Hardware Arrives</h2> The parts for the SO-101</a> showed up from AliExpress. It's a 6-DOF arm designed by TheRobotStudio that uses Feetech STS3215 servos - much more affordable than Dynamixels, though with some trade-offs. Supporting it required two new packages: feetech</a> - Low-level protocol driver for Feetech/WaveShare STS and SCS series servos. Handles the serial communication, register access, and synchronised multi-servo operations. </li> bb_servo_feetech</a> - BB framework integration with controller, actuator, and parameter bridge modules. Same architecture as the Robotis driver. </li> </ol> Fair warning: The Feetech driver is still buggy. The protocol is quirky - load is reported as a percentage rather than mA, status bytes are interpreted differently, and there are some timing sensitivities I'm still working through. Don't use it for anything you can't afford to break just yet. Reactive Controllers</h2> BB v0.13.0 added off-the-shelf controllers that monitor PubSub messages and trigger actions: # Disarm if servo current exceeds limit controller :over_current, {BB.Controller.Threshold, topic: [:sensor, :servo_status], field: :current, max: 1.21, action: command(:disarm) } # React to proximity sensor controller :collision, {BB.Controller.PatternMatch, topic: [:sensor, :proximity], match: fn msg -> msg.payload.distance < 0.05 end, action: command(:disarm) }</code></pre> Useful for safety interlocks and event-driven behaviours without writing custom controller modules. Simulation Mode Improvements</h2> BB v0.13.1 fixes a paper cut: joint sliders in simulation mode now actually update the 3D visualisation. The problem was that simulated actuators publish BeginMotion</code> events but the visualisation needs JointState</code> messages. The fix automatically creates OpenLoopPositionEstimator</code> sensors for each actuator when running with simulation: :kinematic</code>. One less thing to configure manually. bb_servo_robotis on Hex</h2> Finally pushed the button. bb_servo_robotis v0.2.1</a> is on Hex. Nothing exciting, just structured errors in the parameter bridge. But it's no longer "release imminent" - it's actually released. Structured Errors Everywhere</h2> Speaking of structured errors, bb_servo_pca9685 v0.5.0</a> migrated to the same system. All servo drivers now return proper error structs instead of bare tuples. Debugging is easier when error messages tell you what actually went wrong. All The Releases</h2> Since January 5th: Package</th> Version</th> What changed</th></tr></thead> bb</td> v0.13.1</a></td> Auto-add position estimators in simulation mode</td></tr> bb</td> v0.13.0</a></td> Reactive controllers (Threshold, PatternMatch)</td></tr> bb_reactor</td> v0.2.0</a></td> Reactor saga orchestration for task sequencing</td></tr> feetech</td> v0.2.0</a></td> Feetech/STS/SCS protocol driver</td></tr> bb_servo_feetech</td> v0.2.0</a></td> BB integration for Feetech servos (experimental)</td></tr> bb_kino</td> v0.3.2</a></td> Filter omitted bridges in simulation mode</td></tr> bb_kino</td> v0.3.1</a></td> Fix direct actuator commands</td></tr> bb_liveview</td> v0.2.3</a></td> Handle simulation mode and command completion</td></tr> bb_liveview</td> v0.2.2</a></td> Fix direct actuator commands</td></tr> bb_liveview</td> v0.2.1</a></td> Support BB 0.13+ command API</td></tr> bb_servo_robotis</td> v0.2.1</a></td> Structured errors in parameter bridge</td></tr> bb_servo_pca9685</td> v0.5.0</a></td> Migrate to structured error system</td></tr> </tbody></table> What's Next</h2> Getting the Feetech driver stable is the priority. Once that's working reliably, the SO-101 becomes a much more accessible reference platform than the WidowX-200. After that: probably one of the proposals. The teleoperation framework is tempting - it would be nice to wave a spacemouse around and have the arm follow. Links</h2> bb on Hex</a> (v0.13.1)</li> bb_reactor on Hex</a> (v0.2.0)</li> feetech on Hex</a> (v0.2.0)</li> bb_servo_feetech on Hex</a> (v0.2.0)</li> Beyond Behaviour Trees blog post</a></li> Proposals repo on GitHub</a></li> Discord</a></li> </ul> Beyond Behaviour Trees: Task Orchestration the Elixir Way 2026-01-09T00:00:00+00:00 Robot arms don't just move to positions. They pick things up, put them down, respond to sensor feedback, and recover when something goes wrong. Orchestrating these multi-step sequences is one of the harder problems in robotics software. The standard answer in ROS land is behaviour trees. We went a different direction. What's a Behaviour Tree?</h2> If you're already familiar with behaviour trees, skip to the next section</a>. A behaviour tree is a way to structure complex robot behaviours as a tree of nodes. Each node is either a leaf (an action like "move arm" or a condition check like "is object detected?") or a composite that controls execution flow. The key composite types are: Sequence - runs children left-to-right, stops on first failure</li> Selector (or Fallback) - runs children left-to-right, stops on first success</li> Parallel - runs all children simultaneously, with configurable success/failure policies</li> </ul> A pick-and-place behaviour tree might look like this: Sequence ├── Selector │ ├── Condition: "Object in gripper?" │ └── Sequence │ ├── Action: "Move to pick position" │ ├── Action: "Close gripper" │ └── Condition: "Grip force detected?" ├── Action: "Move to place position" └── Action: "Open gripper"</code></pre> The tree gets ticked - a clock pulse that propagates through the tree from root to leaves. Each node returns one of three states: Success, Failure, or Running. The composites use these return values to decide what to do next. This pattern emerged from game AI, where characters need to evaluate their situation continuously and switch behaviours fluidly. It works well for reactive systems that need to constantly reassess their environment. The Tick Problem</h2> Behaviour trees are designed for continuous polling. Every tick, the tree re-evaluates from the root. Is the condition still true? Is the action still running? Should we abort and try a different branch? This polling model makes sense when you're a game character checking if an enemy is nearby sixty times per second. For robot arms? Less so. When I tell my WidowX-200 to move to a position, I don't need to poll it every 16 milliseconds to check if it's still moving. The servo controller knows when motion completes. It can tell me. This is what message-passing systems are built for. Tick-based execution also means your tree traversal logic runs constantly, even when nothing is happening. That's fine on a desktop PC. On a Raspberry Pi running Nerves with other things to do? Every cycle counts. For Elixir developers: Imagine implementing GenServer where instead of receiving messages, you had to poll a check_state/0</code> function in a loop. That's essentially what tick-based behaviour trees ask you to do. For robotics developers: Imagine if your motor controllers just sent you a message when motion completed instead of you having to poll them. That's what Elixir's message passing gives you for free. Enter Reactor</h2> I wrote Reactor</a> as part of my work on the Ash Framework core team. It's a dynamic, concurrent, dependency-resolving saga orchestrator - a mouthful, but the core idea is simple: you define a series of steps with explicit dependencies, and Reactor figures out how to run them. Concurrently where possible, sequentially where necessary. The "saga" part is crucial. In distributed systems, a saga is a sequence of operations where each step can define recovery actions: compensate</code> - what to do if this step fails</li> undo</code> - what to do if a downstream step fails (roll back successful work)</li> </ul> This gives you transaction-like semantics across operations that can't actually be wrapped in a database transaction. Like, say, robot movements. Reactor already handles all the hard parts: dependency graph resolution, concurrent execution, error propagation, rollback coordination. It's been battle-tested in production Ash applications. Building robotics-specific steps on top of it was straightforward. BB.Reactor</h2> The bb_reactor</code> package extends Reactor with robotics-specific steps. Here's the demo sequence from our WidowX-200 example: defmodule BB.Example.WX200.Reactor.DemoSequence do use Reactor, extensions: [BB.Reactor] wait_for_state :ready do states [:idle] timeout 5000 end command :go_home do command :home wait_for :ready end command :trace_circle do command :demo_circle wait_for :go_home end command :return_home do command :home wait_for :trace_circle end return :return_home end</code></pre> No tick loop. No polling. The reactor waits for the robot to reach idle state, then executes commands in sequence, each waiting for the previous to complete via message passing. The DSL provides three step types: command</code> - executes a BB command (like moving or gripper control). Can specify a compensate</code> handler for failure recovery. wait_for_event</code> - subscribes to the BB PubSub and waits for a matching message. Useful for sensor feedback like "wait until force sensor detects grip". wait_for_state</code> - waits for the robot state machine to reach a target state. Why This Matters</h2> Safe Failure Recovery</h3> command :move_to_place do command :move_to_pose argument :target, input(:place_pose) wait_for :grip_confirmed compensate :return_home end</code></pre> If this movement fails, the reactor runs the :return_home</code> command to recover. The arm doesn't get left in an unknown state. Behaviour trees have no built-in concept of compensation. You can implement it, but you're on your own. Dependency-Driven Concurrency</h3> Reactor analyses the dependency graph and runs independent steps in parallel automatically. If two steps don't depend on each other, they execute concurrently. command :prepare_gripper do command :open_gripper wait_for :ready end command :move_to_approach do command :move_to_pose argument :target, input(:approach_pose) wait_for :ready end # Both run in parallel - they only depend on :ready command :grip do command :close_gripper wait_for [:prepare_gripper, :move_to_approach] # waits for both end</code></pre> With behaviour trees, you'd need explicit Parallel nodes and careful tree structure to achieve the same thing. Event-Driven, Not Poll-Driven</h3> Steps block on actual events, not tick cycles: wait_for_event :grip_confirmed do path [:sensor, :force_torque] message_types [ForceTorque] filter &(&1.payload.force > 5.0) timeout 2000 end</code></pre> This subscribes to the force/torque sensor topic and waits for a message where force exceeds 5N. No polling. The step completes the moment the message arrives. Safety Integration</h3> BB.Reactor monitors for safety state changes. If the robot disarms mid-sequence (emergency stop, hardware fault, whatever), the reactor halts immediately with {:halt, :safety_disarmed}</code>. No more steps execute. The command step watches the command process and detects disarm events automatically. You don't have to sprinkle safety checks throughout your tree. The Trade-Off</h2> Behaviour trees excel at reactive, continuous behaviours - things that need to constantly reassess the environment and switch strategies. A robot navigating a dynamic environment, dodging obstacles in real-time, might genuinely benefit from tick-based evaluation. Reactor sagas excel at structured task sequences - things with clear steps, dependencies, and rollback requirements. Assembly operations, pick-and-place, inspection sequences. Behaviour trees aren't wrong. They're just not the only tool, and for the kind of deterministic task orchestration that robot arms typically need, sagas are a better fit. Plus, they're already built on the patterns Elixir gives you for free. Links</h2> bb_reactor on Hex</a> (v0.2.0)</li> Reactor on Hex</a></li> bb on Hex</a></li> bb_example_wx200 on GitHub</a></li> Discord</a></li> </ul> Behaviour Tree Implementations (for comparison)</h3> BehaviorTree.CPP</a> - C++ library used with ROS2</li> py_trees</a> - Python library, also used with ROS</li> SMACH</a> - ROS state machine library (predecessor pattern)</li> </ul> Week Four: Robots Learn to Not Hit Themselves 2026-01-05T00:00:00+00:00 The headline this week: your robot can now check whether it's about to punch itself in the face. Progress! Development has been slower than I'd hoped - turns out New Year's celebrations and summer holidays here in New Zealand aren't particularly conducive to writing code. Who knew? Still, we've got some solid updates. Real Hardware, Real Motion</h2> The WidowX 200 is alive and moving. Commands execute, the DLS IK solver works, and I've had the end effector tracing circles in space. It's one thing to watch simulated joint positions update in Livebook - it's quite another to hear servos whine and watch an actual robot arm follow your commands. More videos and documentation coming once I've cleaned up the example code. Collision Detection</h2> BB v0.11 adds a proper two-phase collision detection system: Broad phase: Fast AABB (axis-aligned bounding box) overlap tests to quickly eliminate non-colliding pairs</li> Narrow phase: Precise intersection tests for spheres, capsules, cylinders, and boxes</li> Mesh support: Load STL files with automatic bounding computation</li> </ul> # Will the robot collide with itself at these joint positions? BB.Collision.self_collision?(robot, positions) # Check with a safety margin (catches near-misses) BB.Collision.detect_self_collisions(robot, positions, margin: 0.01) # Environment obstacles too obstacles = [BB.Collision.obstacle(:sphere, centre, radius)] BB.Collision.collides_with?(robot, positions, obstacles)</code></pre> The system automatically excludes adjacent links from self-collision checks (your elbow is supposed to touch your shoulder). And yes, you can define collision volumes using a new capsule</code> DSL entity. IK Solvers: "Actually, No"</h2> The DLS solver now integrates with collision detection: # Reject solutions that would cause self-collision DLS.solve(robot, positions, :tip, target, check_collisions: true) # With a safety margin DLS.solve(robot, positions, :tip, target, check_collisions: true, collision_margin: 0.01 )</code></pre> When a solution would cause a collision, you get a proper structured error: {:error, %BB.Error.Kinematics.SelfCollision{ link_a: :forearm, link_b: :base, joint_positions: %{shoulder: 1.2, elbow: -2.1} }}</code></pre> This is the kind of thing you want to know before you command the motion, not after. Commands Get Interruptible</h2> BB v0.12 converts commands from Tasks to GenServers. Why does this matter? Because now commands can respond to events during execution. The big win: if you hit the E-stop while a MoveTo</code> is in progress, the command actually stops. Previously it would run to completion regardless (the actuators would ignore commands while disarmed, but the command itself kept chugging along). Commands now implement a proper behaviour with callbacks: handle_command/3</code> - Do the work (signature changed significantly)</li> result/1</code> - Extract result from state</li> handle_safety_state_change/2</code> - React when safety state changes</li> handle_options/2</code> - React when parameters change at runtime</li> </ul> Breaking change: If you've written custom commands, they need updating. The handle_command</code> callback works differently now. Check the commands tutorial</a> for the new pattern. Parameters Widget for Livebook</h2> BB Kino v0.3 adds a BB.Kino.Parameters</code> widget. View and edit your robot's parameters directly in Livebook: Tab-based UI groups parameters logically</li> Remote bridge parameters get their own tabs</li> Input controls match parameter types (toggles for booleans, sliders for bounded numbers, etc.)</li> Real-time updates via PubSub</li> Validation feedback when setting invalid values</li> </ul> The widget slots in at the bottom of the "Manage robot" Smart Cell, full-width. The Robotis Situation</h2> Good news! The upstream robotis v0.2.0</a> landed on Hex on New Year's Eve. This includes our contributed XM430 support, table parameterisation, and raw read/write API. Bad news: I haven't had time to cut the bb_servo_robotis</code> release yet. The driver is ready, tested, and waiting. Just needs someone (me) to push the button. It's on the list. All The Releases</h2> Since December 29: Package</th> Version</th> What changed</th></tr></thead> bb</td> v0.12.0</a></td> Interruptible commands (GenServer-based)</td></tr> bb</td> v0.11.0</a></td> Collision detection system</td></tr> bb_ik_dls</td> v0.3.1</a></td> Update for bb 0.12 command API</td></tr> bb_ik_dls</td> v0.3.0</a></td> Self-collision checking in IK solver</td></tr> bb_ik_fabrik</td> v0.3.1</a></td> Update for bb 0.12 command API</td></tr> bb_kino</td> v0.3.0</a></td> Parameters widget, bb 0.12 compatibility</td></tr> robotis</td> v0.2.0</a></td> (upstream) XM430 support, raw API</td></tr> </tbody></table> What's Next</h2> Parts for an SO-101</a> are on their way from AliExpress. Designed by TheRobotStudio, it's a capable, affordable arm that should make a good reference platform for folks who want to try Beam Bots without dropping serious cash on Dynamixel servos. In the meantime: more IK work, better joint limit enforcement, and getting bb_servo_robotis</code> onto Hex. Links</h2> bb on Hex</a> (v0.12.0)</li> bb_ik_dls on Hex</a> (v0.3.1)</li> bb_ik_fabrik on Hex</a> (v0.3.1)</li> bb_kino on Hex</a> (v0.3.0)</li> bb_liveview on Hex</a> (v0.2.0)</li> bb_servo_pca9685 on Hex</a> (v0.4.0)</li> bb_servo_pigpio on Hex</a> (v0.4.0)</li> bb_servo_robotis on GitHub</a> (Hex release imminent)</li> robotis on Hex</a> (v0.2.0)</li> Discord</a></li> </ul> Week Three: No Hardware? No Problem 2025-12-29T00:00:00+00:00 What do you do when your robot parts are still in transit from China? You build a simulation mode, obviously. Simulation Mode</h2> The headline feature this week: robots can now run entirely in software. Pass simulation: :kinematic</code> when starting your robot and the framework swaps in simulated actuators that honour joint velocity limits and publish motion events - but don't require any actual hardware. # Run without hardware MyRobot.start_link(simulation: :kinematic) # Check mode at runtime BB.Robot.Runtime.simulation_mode(MyRobot) # => :kinematic</code></pre> The safety system still works (you must arm before commanding motion), position feedback flows through OpenLoopPositionEstimator</code> as normal, and your LiveView dashboard lights up just like it would with real servos. The main difference? No angry servo noises at 2am. Controllers and bridges can opt into different simulation behaviours via DSL options: controllers do controller :pca9685, {BB.Servo.PCA9685.Controller, bus: "i2c-1"}, simulation: :omit # Don't start in simulation end</code></pre> This lets you test your robot's logic, supervision tree, and dashboard without touching hardware. Handy for development, CI pipelines, and waiting for slow boats from Shenzhen. param() References: Configuration Gets Pleasant</h2> The param()</code> function now works everywhere in your robot DSL. Define parameters in one place, reference them anywhere - actuator options, controller configuration, even topology fields like joint limits. parameters do namespace :config do namespace :robotis do param :device, type: :string param :baud_rate, type: :integer, default: 1_000_000 end end end controllers do controller :dynamixel, {BB.Servo.Robotis.Controller, port: param([:config, :robotis, :device]), baud_rate: param([:config, :robotis, :baud_rate]) } end</code></pre> Then pass values when starting: # In your application.ex {MyRobot, [ parameters: [ config: [robotis: [ device: Application.get_env(:my_app, :robotis_device), baud_rate: Application.get_env(:my_app, :robotis_baud) ]] ] ]}</code></pre> This separates hardware configuration from robot definition. Your robot DSL describes the structure - what joints connect where, which actuators drive which joints. The runtime details (which USB port, what baud rate) come from your application config, environment variables, or wherever makes sense for your deployment. Even better: when parameters change at runtime, actuators get notified via a handle_options/2</code> callback. Hot-reconfiguration without restarts. Math Gets Serious</h2> The core framework now includes proper mathematical types: BB.Math.Vec3</code> - 3D vectors backed by Nx tensors, with operations like cross/2</code>, normalise/1</code>, and unit vector constructors</li> BB.Math.Quaternion</code> - unit quaternions for rotations, including slerp/3</code>, from_axis_angle/2</code>, and rotate_vector/2</code></li> BB.Math.Transform</code> - 4x4 homogeneous transformation matrices, now properly struct-wrapped</li> </ul> These types form the foundation for all spatial reasoning in Beam Bots. If you're passing position and orientation around, use Transform</code> - it's the canonical representation for poses in robotics (SE(3) if you're into that sort of thing). Orientation-Aware Inverse Kinematics</h2> The FABRIK solver grew up. It now understands that sometimes you don't just want the gripper at a position - you want it pointing in a particular direction. # Point the tool along the Z axis BB.Motion.move_to(robot, :gripper, {position, {:axis, Vec3.unit_z()}}, BB.IK.FABRIK) # Full orientation constraint BB.Motion.move_to(robot, :gripper, {position, {:quaternion, target_orientation}}, BB.IK.FABRIK) # Or just pass a Transform BB.Motion.move_to(robot, :gripper, target_transform, BB.IK.FABRIK)</code></pre> The solver tracks orientation at each joint internally, which also fixes some edge cases with spherical joints (co-located axes like you find in shoulder and wrist assemblies). Still early stage. Joint limits aren't enforced and collision detection doesn't exist. But it's moving in the right direction. bb_servo_robotis: Progress Report</h2> Good news: our upstream PR</a> to pkinney/robotis</code> merged on Christmas Eve. The changes add XM430 servo support, table parameterisation, and a raw read/write API. Bad news: we're still waiting on a Hex release from upstream before we can publish bb_servo_robotis</code>. The package works fine if you're willing to pull from git, but we want clean Hex dependencies before we call it "released". In the meantime, the driver itself got updates: Wrapper GenServer pattern from bb 0.8</li> Hardware error reporting to the safety system</li> Configurable disarm behaviour</li> Structured errors and diagnostic telemetry</li> </ul> When upstream publishes, we'll be ready to ship the same day. Better Errors, Better Telemetry</h2> The framework adopted Splode</a> for structured error handling. Errors now have proper types, stack traces, and can be pattern-matched sensibly. No more parsing error message strings. We also added diagnostic telemetry events. If you're running :telemetry</code> (and you should be), you'll see performance metrics and diagnostic events flowing through. Useful for debugging and for building monitoring dashboards. All The Releases</h2> Since December 22: Package</th> Version</th> What changed</th></tr></thead> bb</td> v0.10.0</a></td> Simulation mode, Vec3/Quaternion/Transform</td></tr> bb</td> v0.9.0</a></td> Splode errors, telemetry</td></tr> bb</td> v0.8.0</a></td> param() refs, wrapper GenServer pattern</td></tr> bb_ik_fabrik</td> v0.3.0</a></td> Orientation-aware solving</td></tr> bb_servo_pca9685</td> v0.4.0</a></td> Structured errors</td></tr> bb_servo_pigpio</td> v0.4.0</a></td> Structured errors</td></tr> </tbody></table> Happy New Year</h2> To those who celebrate: enjoy the fireworks, make some resolutions you won't keep, and try not to think about how much work is waiting for you in January. To those who don't: enjoy the quiet internet. Again. See you in 2025. Wait, we're already in 2025. See you next year. Which is also 2025. You know what I mean. Links</h2> bb on Hex</a> (v0.10.0)</li> bb_ik_fabrik on Hex</a> (v0.3.0)</li> bb_liveview on Hex</a> (v0.2.0)</li> bb_kino on Hex</a> (v0.2.0)</li> bb_servo_pca9685 on Hex</a> (v0.4.0)</li> bb_servo_pigpio on Hex</a> (v0.4.0)</li> bb_servo_robotis on GitHub</a> (coming to Hex soon)</li> Discord</a></li> </ul> Week Two: Tell It Where, Not How 2025-12-22T00:00:00+00:00 The WidowX-200 that Frank donated? It moves now. Under Elixir control. This is not a drill. The Arm Lives</h2> After a week of hacking on Dynamixel protocol support, I can now command the WidowX-200's servos directly from Beam Bots. The bb_servo_robotis</code> package handles the full integration: Actuator control - set joint positions and the arm actually goes there</li> Sensor telemetry - real-time temperature, voltage, current draw, and hardware error monitoring</li> Parameter bridges - read firmware versions, tune PID controllers, and access servo configuration through the BB parameter system</li> </ul> All of this talks to the hardware via the Robotis Protocol 2.0</a> over a U2D2 USB adapter. The robotis</code> package (our fork of pkinney/robotis</a>) handles the low-level protocol, and bb_servo_robotis</code> wraps it into Beam Bots actuators, controllers, and sensors. The package isn't on Hex yet because it depends on our fork via git. Once our upstream PR</a> merges, we'll publish. Patience, young padawan. Inverse Kinematics (Early Stage)</h2> The new bb_ik_fabrik</code> package implements the FABRIK algorithm</a> for inverse kinematics. Instead of saying "rotate joint 1 to 45 degrees, joint 2 to 30 degrees...", you can say "put the gripper at position (x, y, z)" and the solver figures out the joint angles. The core framework got a matching BB.Motion</code> API that ties it all together: # Move the gripper to a point in space BB.Motion.move_to(robot, :gripper, {0.3, 0.1, 0.2}, BB.IK.FABRIK) # Or solve without sending commands (for validation) {:ok, joint_positions} = BB.Motion.solve_only(robot, :gripper, target, BB.IK.FABRIK)</code></pre> Fair warning: The FABRIK solver is very early stage. It currently ignores joint constraints and collision detection, which means it can produce solutions that exceed your joint limits or send your arm through itself. Use it in simulation only, or on real hardware with extreme caution. This will improve, but right now it's a "trust but verify" situation - emphasis on verify. Multi-target solving runs in parallel for coordinated motion, which will be useful for gait generators once the solver matures. LiveView Dashboard</h2> The bb_liveview</code> package is now on Hex. One line of code in your Phoenix router and you get: Safety arm/disarm controls with visual state indicators</li> Joint sliders with real-time position feedback</li> Interactive 3D visualisation (Three.js) that updates as the robot moves</li> PubSub event stream viewer with filtering</li> Command execution forms generated from your robot's DSL</li> Parameter management for runtime configuration</li> </ul> This is the "introspection dashboard" from the roadmap, now shipping. Mount it in your app and control your robot from a browser. Core Framework Updates</h2> BB itself went through three releases this week: v0.5.0 - Motion integration with IK solvers and actuator commands. The BB.Motion</code> module bridges solving and commanding in a single call. v0.6.0 - New BB.Controller</code>, BB.Sensor</code>, and BB.Bridge</code> behaviours with options_schema</code> callbacks. Each behaviour now includes use GenServer</code>, so your implementations get GenServer for free. The schema validation catches misconfigured child specs at compile time. v0.7.0 - Hardware error reporting with auto-disarm. Controllers can call BB.Safety.report_error/3</code> when hardware problems occur, and the safety system will automatically disarm (configurable via auto_disarm_on_error</code>). The servo driver packages (bb_servo_pca9685</code> v0.3.1, bb_servo_pigpio</code> v0.3.1) updated to use the new behaviours. Coming in 2026: A Budget Robot Arm</h2> The WidowX-200 is excellent hardware, but it costs about $3,500 USD. Not exactly impulse-buy territory for someone wanting to experiment with robotics. I've ordered parts to build an SO-101</a> - an open-source 6-DoF arm designed by The Robot Studio and Hugging Face for AI training and teleoperation. Total cost: around $120-230 USD depending on where you source parts. The servos are Waveshare ST3215s, and the frame is 3D printed. The goal is to make this a documented "getting started" path for Beam Bots - print the arm, wire it up, follow the tutorial, have a working robot controlled by Elixir. More accessible than "go buy a $3,500 arm" anyway. Happy Christmas</h2> This Thursday is Christmas Day. To those who celebrate: enjoy the time with family, eat too much, and try not to argue about politics. To those who don't celebrate: enjoy the quiet internet. See you in 2026. Links</h2> bb on Hex</a> (v0.7.0)</li> bb_ik_fabrik on Hex</a> (v0.2.0)</li> bb_liveview on Hex</a> (v0.2.0)</li> bb_kino on Hex</a> (v0.2.0)</li> bb_servo_pca9685 on Hex</a> (v0.3.1)</li> bb_servo_pigpio on Hex</a> (v0.3.1)</li> bb_servo_robotis on GitHub</a> (coming to Hex soon)</li> bb_example_wx200 on GitHub</a></li> SO-101 Robot Arm</a></li> Discord</a></li> </ul> Week One: Discord, Robot Arms, and Livebook Widgets 2025-12-15T00:00:00+00:00 It's been six days since I announced Beam Bots, and things have moved faster than expected. Here's what happened. We Have a Discord Channel</h2> The Elixir Discord community has given Beam Bots its own #beam-bots</code> channel. If you want to chat about resilient robotics on the BEAM, ask questions, or just lurk, come say hello</a>. Frank Hunleth Donated a Robot Arm</h2> Frank Hunleth</a>, co-creator of Nerves, has donated a Trossen Robotics WidowX-200</a> 5-DoF robot arm to the project. This is a proper piece of kit - Dynamixel servos, aluminium construction, and enough reach to knock things off my desk. This means I'll be able to test Beam Bots against real hardware that isn't just a servo taped to a breadboard. Expect tutorials and examples using this arm as the development progresses. Thanks Frank. BB Kino: Livebook Widgets for Robot Control</h2> The biggest code drop this week is bb_kino</a> - a suite of interactive Livebook widgets for controlling and monitoring BB robots. The package includes: Safety Widget - arm/disarm controls with real-time state indicators</li> Joint Control Widget - sliders for setting joint positions, respecting limits</li> Event Stream Widget - live message monitoring with path filtering</li> Command Widget - dynamic forms for executing robot commands</li> 3D Visualisation Widget - interactive Three.js rendering with real-time joint updates</li> Manage Robot Smart Cell - a unified dashboard combining everything</li> </ul> This isn't the "LiveView-based introspection" from the roadmap - that's still planned as an embeddable dashboard for Phoenix apps. But for prototyping and development, being able to control your robot interactively in Livebook while watching state update in real-time is pretty useful. Safety System</h2> BB v0.4.0 adds BB.Safety</code>, a centralised arm/disarm controller that ensures your robot can always be stopped safely. Key features: BB.Safety</code> behaviour - actuators controlling hardware implement a disarm/1</code> callback</li> Global safety state - one place to arm or disarm all safety-registered components</li> Error state handling - if disarm callbacks fail, the robot enters an :error</code> state and won't re-arm until you explicitly acknowledge with force_disarm/1</code></li> Documentation covering BEAM's soft real-time limitations and why you still need a hardware kill switch</li> </ul> The safety system is critical infrastructure. When things go wrong, you need the disarm to work even if the process that controlled the actuator has crashed. The disarm/1</code> callback is designed to work without GenServer state for exactly this reason. Servo Driver Packages</h2> Two new packages for driving RC servos: bb_servo_pigpio</a> - drives servos via GPIO PWM on Raspberry Pi using pigpio. Good for simple setups with a few servos directly connected to GPIO pins. bb_servo_pca9685</a> - drives servos via the PCA9685 16-channel PWM controller over I2C. Better for projects needing more channels or cleaner wiring. Both packages implement BB.Safety</code> for safe disarm, use the standard actuator command interface, and work with BB.Sensor.OpenLoopPositionEstimator</code> for position feedback on servos without encoders. Other Changes</h2> Standard actuator command interface - BB.Actuator.set_position/4</code> and friends provide a consistent API across all actuator types</li> OpenLoopPositionEstimator - estimates joint position over time based on commanded velocity, for servos that don't report their actual position</li> BeginMotion/EndMotion messages - actuators now publish motion lifecycle events for coordination and logging</li> </ul> What's Next</h2> The WidowX-200 uses Dynamixel servos with their own protocol, so I'll be writing a Dynamixel driver package. After that, I want to get inverse kinematics working so I can command the arm to move to a point in space rather than specifying individual joint angles. The rover project is on hold until the arm is working. One robot at a time. Links</h2> bb on Hex</a> (v0.4.0)</li> bb_kino on Hex</a> (v0.2.0)</li> bb_servo_pigpio on Hex</a> (v0.3.0)</li> bb_servo_pca9685 on Hex</a> (v0.3.0)</li> Discord</a></li> GitHub: beam-bots</a></li> </ul> Announcing Beam Bots: Resilient Robotics on the BEAM 2025-12-09T00:00:00+00:00 I've been working on something I'm excited to share: Beam Bots</a>, a framework for building resilient robotics applications in Elixir. It's early days - the code hasn't controlled any physical robots yet - but the core is there and I'm looking for feedback and contributors. If you're an Elixir developer who's ever been curious about robotics, read on. Why Not Just Use ROS?</h2> As a hobby roboticist I've looked at ROS</a> (Robot Operating System) for my projects. ROS is the industry standard, and for good reason - it solves real problems around inter-process communication, hardware abstraction, and tooling for robotics development. But ROS is designed for a different context than my hobby projects. You're expected to deploy a full Ubuntu system with a stack of packages on top of it. There are no OS images, no A/B firmware systems, no turnkey deployment story. ROS gives you the flexibility to design systems using many different technologies, but that flexibility comes with complexity. For my hobby projects, I wanted something lighter. ROS Looks a Lot Like OTP</h2> This isn't a new observation for me. I wrote about this back in 2020 hoping someone else would build the tooling. Five years later, nobody had, so here we are. When reading about ROS2's architecture, the pattern becomes obvious: so much of what ROS provides are just stock BEAM/OTP/Elixir patterns. ROS2's pubsub for inter-node communication? Elixir has Phoenix.PubSub</code>, Registry</code>, and built-in process messaging.</li> ROS2's Services (request/response)? That's GenServer.call/3</code>.</li> ROS2's Actions (long-running tasks with feedback)? That's a supervised Task</code> with progress messages.</li> ROS2's Controllers managing robot behaviour? GenServers with state machines.</li> ROS2's lifecycle nodes? GenServers with explicit state transitions.</li> ROS2's parameter system? That's ETS.</li> </ul> The BEAM already gives you fault tolerance, massive concurrency, soft real-time performance, and excellent behaviour in resource-constrained environments. Why reinvent all of that? What Beam Bots Provides</h2> Beam Bots builds on this insight. It provides: A Spark DSL for declarative robot definitions. Your robot's topology - links, joints, sensors, actuators - is defined in code that mirrors the physical structure. Here's a simple pan-tilt camera mount: defmodule PanTiltCamera do use BB topology do link :base_link do visual do cylinder do radius ~u(0.03 meter) height ~u(0.02 meter) end end joint :pan_joint do type :revolute origin do z ~u(0.015 meter) end limit do lower ~u(-170 degree) upper ~u(170 degree) end link :pan_link do joint :tilt_joint do type :revolute limit do lower ~u(-45 degree) upper ~u(90 degree) end link :camera_link end end end end end end</code></pre> The nesting in the code directly reflects the nesting in the physical robot. If you can read the code, you can understand the structure. Because it's a DSL built on Elixir macros, you can metaprogram your robots. Something as simple as for arm <- [:left, :right], do: joint(...)</code> to avoid repetition, or as sophisticated as writing a Spark DSL extension that transforms your robot definition at compile time. Topology-based supervision. When you start a robot, Beam Bots builds a supervision tree that mirrors your robot's physical topology. Why does this matter? Fault isolation. If code controlling a gripper crashes repeatedly, the restart intensity propagates up through the supervision tree. A failing component further down the topology takes longer to impact the entire system, giving your robot more time to reach a safe state. Physical units with the ~u</code> sigil. Express measurements naturally - ~u(90 degree)</code>, ~u(0.5 meter)</code>, ~u(10 newton_meter)</code> - with automatic conversion to SI base units internally. Forward kinematics using Nx</a>. Compute the position of any link in your robot's kinematic chain using efficient tensor operations. On supported systems, these calculations can run on the GPU. Hierarchical PubSub for sensor data. Subscribe to sensor topics using path-based addressing with optional message type filtering. Want all IMU data from the left arm? subscribe(MyRobot, [:sensor, :left_arm], message_types: [BB.Message.Sensor.Imu])</code>. URDF export. Need to visualise your robot in Gazebo or integrate with ROS tools? Export your robot definition to URDF with mix bb.to_urdf MyRobot -o robot.urdf</code>. Where It Runs</h2> Beam Bots runs anywhere Elixir runs: Nerves devices - from Raspberry Pi to custom hardware, managed at scale via NervesHub with proper OTA updates and A/B firmware</li> Distributed Erlang clusters - multiple devices inside a single robot system can communicate transparently</li> A single PC running Livebook - prototype and experiment interactively</li> </ul> The only requirement is Nx support for the kinematics calculations. Current Status</h2> I want to be upfront: Beam Bots hasn't controlled any physical robots yet. The framework compiles, the tests pass, the DSL works, but I haven't closed the loop with actual hardware. That's changing. I'm currently building a Mars-style rover with rocker-bogie suspension and YOLO-based object detection and avoidance. Updates will follow as I make progress. What's Next</h2> The roadmap includes: Inverse kinematics using the FABRIK algorithm</li> Simulation support with Gazebo and/or Webots integration</li> Protocol bridges for MAVLINK, MSP, Crossfire, and other common robotics protocols</li> Extension packages providing out-of-the-box support for common sensors and actuators</li> LiveView-based introspection for monitoring and debugging running robots</li> Kino plugins for rich robotics interactions in Livebook</li> </ul> Get Involved</h2> Beam Bots is published on Hex as bb</code></a>. The easiest way to get started is with Igniter: mix igniter.install bb</code></pre> If this sounds interesting, I'd love your feedback: GitHub: beam-bots/bb</a> - browse the code, open issues, send PRs</li> Documentation</a> - tutorials and API reference</li> Try defining a robot and let me know where the DSL feels awkward</li> If you have robotics hardware, help me close the loop with real-world testing</li> </ul> This isn't production ready. But it's ready for exploration, and I think there's something here worth building together.

What's Next</h2>
The servo driver rework is the priority. Once that's solid, the SO-101 demo video can finally happen. For real this time. Probably.</p>

Week Nine: No Hardware Required

Week Eight: New Digs

Links</h2>
bb on Hex</a> (v0.15.0)</li>
Proposals repo on GitHub</a></li>
Discord</a></li> </ul>

Week Seven: Jido Enter Stage Left

Links</h2>

bb on Hex</a> (v0.15.0)</li>
Jido on Hex</a></li>
Proposals repo on GitHub</a></li>
Discord</a></li> </ul>

Week Six: Balance Bots and Better State Machines

What's Next</h2>
Getting the SO-101 experience polished remains the priority. Once that's solid, I can start making videos that don't require a $2000 robot arm.</p>
The balance bot collaboration with Gus is exciting, but it's hardware-dependent - we need the Starter Kit design locked down first.</p>

Week Five: Tasks Get Orchestrated, Roadmaps Get Transparent

Structured Errors Everywhere</h2>
Speaking of structured errors, bb_servo_pca9685 v0.5.0</a> migrated to the same system. All servo drivers now return proper error structs instead of bare tuples. Debugging is easier when error messages tell you what actually went wrong.</p>

Beyond Behaviour Trees: Task Orchestration the Elixir Way

Behaviour Tree Implementations (for comparison)</h3>

BehaviorTree.CPP</a> - C++ library used with ROS2</li>
py_trees</a> - Python library, also used with ROS</li>
SMACH</a> - ROS state machine library (predecessor pattern)</li> </ul>

Week Four: Robots Learn to Not Hit Themselves

Week Three: No Hardware? No Problem

Week Two: Tell It Where, Not How

Week One: Discord, Robot Arms, and Livebook Widgets

We Have a Discord Channel</h2>
The Elixir Discord community has given Beam Bots its own `#beam-bots</code> channel. If you want to chat about resilient robotics on the BEAM, ask questions, or just lurk,` `come say hello</a>.</p>`

Links</h2>

bb on Hex</a> (v0.4.0)</li>
bb_kino on Hex</a> (v0.2.0)</li>
bb_servo_pigpio on Hex</a> (v0.3.0)</li>
bb_servo_pca9685 on Hex</a> (v0.3.0)</li>
Discord</a></li>
GitHub: beam-bots</a></li> </ul>

Announcing Beam Bots: Resilient Robotics on the BEAM

Beam Bots

Week Thirteen: Other People's Robots

What's Next</h2>
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</a>.</p>

Week Eleven: The Quiet Fortnight

Beam Bots

Week Thirteen: Other People's Robots

What's Next</h2> 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</a>.</p>

Week Eleven: The Quiet Fortnight

What's Next</h2> The servo driver rework is the priority. Once that's solid, the SO-101 demo video can finally happen. For real this time. Probably.</p>

Week Nine: No Hardware Required

Week Eight: New Digs

Week Seven: Jido Enter Stage Left

Week Six: Balance Bots and Better State Machines

Nerves Starter Kit Balance Bot</h2> The most exciting news this week isn't a package release - it's a collaboration.</p>

Documentation Gardening</h2> All three packages (bb, bb_kino, bb_liveview) got a documentation tidy-up this week.</p>

Week Five: Tasks Get Orchestrated, Roadmaps Get Transparent

Beyond Behaviour Trees: Task Orchestration the Elixir Way

BB.Reactor</h2> The bb_reactor</code> package extends Reactor with robotics-specific steps. Here's the demo sequence from our WidowX-200 example:</p>

Week Four: Robots Learn to Not Hit Themselves

Week Three: No Hardware? No Problem

Week Two: Tell It Where, Not How

The Arm Lives</h2> After a week of hacking on Dynamixel protocol support, I can now command the WidowX-200's servos directly from Beam Bots. The bb_servo_robotis</code> package handles the full integration:</p>

Week One: Discord, Robot Arms, and Livebook Widgets

Safety System</h2> BB v0.4.0 adds BB.Safety</code>, a centralised arm/disarm controller that ensures your robot can always be stopped safely. Key features:</p>

Announcing Beam Bots: Resilient Robotics on the BEAM

What's Next</h2>
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</a>.</p>

What's Next</h2>
The servo driver rework is the priority. Once that's solid, the SO-101 demo video can finally happen. For real this time. Probably.</p>