Author: burf2000

August 2026: Sanbot Native ROS Driver

Posted on by burf2000

Hello and welcome to another Burf Update. This was another active month on the robotics side, with the creation of the first native ROS2 driver for the Sanbot Elf and lots of refinements to the Platform.

Sanbot — a native ROS 2 driver, no bridge

The Sanbot Elf used to reach ROS through a bridge: a Python node on a laptop, polling the robot and republishing everything, so the laptop was on the network on the robot’s behalf. It now speaks DDS itself — the robot is the node. There’s no rclcpp for Android, so the transport is hand-written in Kotlin: discovery, serialisation, reliability, fragmentation, about 2,800 lines, talking to stock ROS 2 with nothing special on the other end. The driver also works with the USB Lidar that I attached to the robot, however, SLAM and Nav2 still need to run on another machine, but I am fine with that.

Keecker — hacking a dead robot back to life

The Keecker is a rolling home projector from a French company that folded years ago — Android inside, no SDK, never meant to be opened. Getting in was the whole job: in device mode its USB port answers Android Open Accessory, so my Mac registered itself as a USB keyboard and mouse and drove the robot’s on-screen menus by remote until I could turn on USB debugging and drop to plain ADB. A small voice-activated driver app now rides on top and re-pairs itself on boot, so the hack was the way in, not the way it runs.

Burf Platform — it docks itself, and drives around things

The Platform gained the two things that separate a demo from something you can leave running. It charges itself: a robot on a route watches its own battery, breaks off when it’s low, docks, charges, and resumes — all afternoon, no human. Both bugs on the way were the robot being correct: it kept undocking because voltage sags twenty points under load, so it charged to 82%, drove off, watched itself read 60%, and reasonably went back; and obstacle avoidance wouldn’t let it dock at all, because the dock is against a wall.

And it drives around things that weren’t on the map. Bumper or LiDAR trips, stop, wait thirty seconds, and if it’s still there mark a robot-sized no-go zone and replan around it. It failed on hardware six different ways against a pair of shoes — a bumper that cancelled its own countdown, a bumper that bounces ten times in two seconds, a released switch mistaken for a clear path — until I made myself write proper unit tests, which caught a seventh bug at the desk. This morning it worked end to end: one bump, one clean hold, a back-off, “New path found around it — 4 leg(s)”, and a neat arc around the shoes.

I had looked to run Nav2 on the TurtleBot, however, it seemed to push the robot past its Jetson Nano limits, which I did find odd.

Robotic Hand

So I have started work on building my own robot. I remodeled an unfinished robotic hand and got a basic demo working which I am happy about.

InMoov — teleoperated from a VR headset

A quieter month after July’s, but the Meta Quest teleop got real use — headset on, move your arms, the humanoid copies you. It’s worked since the end of July.

Plan for 2026 — honest scorecard

  • Strengthen Burf Robotics — steady. Consultancy delivering.
  • Launch Burf Platform as MVP — it docks itself and avoids obstacles now. Still no price and no first customer, which is the real bottleneck, and entirely mine.
  • Continue learning ROS 2 — best month yet: a hand-written RTPS transport on Android, running against stock ROS 2.
  • InMoov Robots — driver and VR teleop both working.
  • Continue Brilliant learning — ongoing.
  • Build my own robot product — already started.

What’s next

I really need to make sure the platform is working well and then focus on building my own robot.

July 2026: Inmoov Quality Time

Posted on by burf2000

Hello and welcome to another Burf Update. July was a month of the robots telling me I was wrong. Six bugs found by watching a robot move, one found by listening to it not move — and every single one of them had passed a test first.

InMoov — a real ROS2 driver

After months of “nothing to report”, the InMoov finally got the attention it deserved. It now has a proper ROS2 interface: a ros2_control hardware driver in C++ talking to MyRobotLab over the network. Drag a slider in RViz and the real robot’s head turns.

The interesting part wasn’t the plumbing; it was the mapping. ROS2 thinks in radians, with a joint at zero when the robot is at rest. The servos think in degrees, 0–180, with a calibrated rest position — and on a hand-built robot those rest positions are nothing like symmetrical. On mine the left shoulder rests at 35° and the right at 62°. So the driver reads every servo’s real minimum, maximum and rest live from the robot at startup. A static table would have been wrong on day one.

Then I started dragging sliders and found six joints moving the wrong way in a single session. The head panned backwards. The shoulders moved in opposite directions to each other. The elbows bent backwards in the simulator while the real arm bent correctly — which is the nasty one, because the robot looks right and you only catch it by watching the 3D model instead of the machine. Each fix was one line. Finding them was the work, and the only tool that found them was a person looking at a robot.

Driving the InMoov from a VR headset

The other half of the month: a Meta Quest app that teleoperates it. Put the headset on, move your arms, and the robot copies you — head, shoulders, biceps, rotation. The rest-position problem came back harder, because a human shoulder and an InMoov shoulder share neither a range nor a zero. I enabled the joints one group at a time, because a wrong sign on a slider is a puzzle and a wrong sign on a life-size arm is a repair.

Two details worth keeping. The head needed an auto-neutral on engage — whatever pose your head is in when you connect becomes zero, or you inherit a permanent bias and fight it all session. And there’s a voice recentre command, because you can’t reach a keyboard wearing a headset with your arms in the air. Best bug of the lot: the code reading each servo’s limits treated a limit of 0.0 as “not set”. Zero is a perfectly ordinary minimum. Every servo whose travel started at zero was silently getting a default instead of the truth.

Sanbot — a real LiDAR, and a brake I couldn’t switch off

The Sanbot’s ROS2 side got honest this month. A real LDS-006 LiDAR over USB drives /scan, replacing the depth-camera hack it had been faking scans with. Closed-loop pose, IMU heading at source, and stepped turning that SLAM can actually follow. Watching a nine-year-old service robot build a map of my hallway was the most satisfying thing I did all month.

Then one long, doomed campaign. The Sanbot has a firmware proximity brake that stops it near obstacles — useful, until ROS2 is doing the navigating and the robot halts a metre short of a waypoint for reasons the planner knows nothing about. I found the switch that disables obstacle avoidance. I re-asserted it at every startup. I sent an undocumented MCU command that looked exactly like the one that would hide the front sensors. It cannot be disabled. The side sensors, yes. The front brake, no — not from software, at any level I can reach. So I deleted every lever I’d built for it and wrote down that it’s impossible, which is worth more than the code was.

TurtleBot2 — a proper LiDAR too

The Kobuki got the same treatment. It had been limping along on a depth-camera scan and an unreliable vendor SDK; it now has a real Okdo LD06 LiDAR publishing /scan through a custom node I wrote against the raw FTDI serial stream. Depth-scan is demoted to a legacy opt-in. Both robots pinned to /dev/serial/by-id paths, because device numbering changes the moment you plug something else in.

Burf Platform — waypoints that actually arrive

The Platform’s goto now drives room-to-room rather than just across open floor. Three fixes made the difference: denoising the occupancy grid before inflating it, treating deep unknown space differently from the thin rind around walls, and making the stall detector rotation-aware so a robot turning on the spot isn’t mistaken for a stuck one.

The inflation padding came down from 0.22 to 0.15 as well. Waypoints near furniture were stopping about a metre short — the goal was being nudged out to the inflation boundary, then the 0.30 accept radius stacked on top of that. Two reasonable numbers making one unreasonable one.

Plan for 2026 — honest scorecard

  • Strengthen Burf Robotics — steady. Consultancy delivering.
  • Launch Burf Platform as MVP — goto is genuinely usable now. Still no price and no first customer, which is the real bottleneck.
  • Continue learning ROS2 — best month yet. A ros2_control driver from scratch, two custom LiDAR nodes, and SLAM on a robot nobody expected to run it.
  • InMoov Robots — finally, properly, yes. Driver working, VR teleop working. (Big progress)
  • Continue Brilliant learning — ongoing.
  • Build my own robot product — paused

What’s next

Finish confirming the remaining joint directions on the InMoov, and finally record a video of the humanoid being teleoperated from a VR headset. That’s worked since the end of July and there’s still no footage of it — which, given it’s the best-looking thing in the workshop, is its own kind of bug.

June 2026: The Robot That Could Strafe (and Never Said So)

Posted on by burf2000

Hello again. Last month was about getting the foundations in shape; this month was about wheels turning and maps building. June was a hardware month — the kind where you spend an evening with a multimeter and a servo that’s spinning the wrong way, and then suddenly a robot does the thing.

The wheelchair robot (built from scratch)

This one ran away from me in the best way. The plan was modest — “mount the Pi, do one RC-driven test run.” Instead, I built the whole robot.

It’s an electric wheelchair turned into a tank-drive robot. Arduino running a DBH-12V dual motor driver (with a verified pin map, which took a couple of goes), RC tank-drive on the sticks, and — the part I’m most pleased with — a latching e-stop with a 300 ms watchdog. If the control link drops, it stops. If you hit the e-stop, it stays stopped until you deliberately reset it. When you’re building something that weighs as much as a person and can pull away from you, that’s not a nice-to-have.

All of it runs through one control daemon: e-stop, RC drive, and onboard journey recording (LiDAR, IMU, GPS, camera) in a single process. The recording side reuses the pipeline I built for the G-Wiz telemetry rig last month — record a run, upload it, replay it in the browser on a map ready for some AI processing.

TurtleBot2 / Kobuki — SLAM on a Jetson, driven through the platform

This one was a resurrection. The Kobuki TurtleBot2 had been sitting unused for years — an ancient NVIDIA Jetson TK1 for a brain, Ubuntu 14, ROS1, the whole lot frozen in time. This month I dragged it into the present: a newer Jetson, and ROS2 Humble running in a Docker container — which is the neatest way to get a modern ROS2 onto older Jetson hardware without reflashing the whole board and fighting its ancient OS. From there, it’s wired into the same control stack as everything else, so I can drive it and watch its map from the browser. Xtion depth camera for the laser scan, slam_toolbox for mapping and multi-waypoint navigation. Driving it to a series of waypoints and watching the map fill in is genuinely satisfying.

Reviving it wasn’t free, though — and the camera is where it bit me. Depth-camera SLAM on the Jetson is right at the edge of what the hardware can do. A real LiDAR gives you a clean 360° scan; a depth camera gives you a narrow forward cone faked into a laser scan, and on a Nano, the whole pipeline is fighting for CPU. You lose the map the moment you turn too fast, and loop closure is fragile because the robot can’t see enough of the world at once. I got it mapping and navigating — but I also got a concrete feel for why people put a proper LiDAR on anything they’re serious about, and why a beefier compute brain (the Jetson Orin on my bench is the obvious upgrade) changes the game. That’s the kind of lesson you can’t read in a tutorial. You have to drive the thing into a wall a few times.

PiBob — ROS2 driver, hardware-verified end-to-end

PiBob (my Pi-brained humanoid) crossed the finish line in ROS2 this month. I went from a URDF that frankly didn’t look like the actual robot — arm meshes floating in the wrong places — to every part correctly seated and mirrored per side, and then I drove the real servos from the RViz sliders.

The hardware test more than earned its keep. It caught a driver bug where the bridge had never actually loaded the joints — so it was cheerfully POSTing nothing to the servos — plus three servos wired to turn the wrong way. None of that shows up in simulation. You only find it when a real arm moves and goes, “That’s not right.”

https://github.com/burf2000/PiBob/tree/main/ros2

The Sanbot turned out to be holonomic — and the SDK never said so

The biggest surprise of the month came from a robot I’ve owned for ages: the Sanbot Elf. I’m building a proper ROS2 driver for it — putting a vendor-locked Android humanoid onto the ROS2 graph with standard topics, so normal robotics tooling can drive it like anything else — and while reverse-engineering its OpenSDK I started poking at the wheel commands one at a time.

It has three omni wheels, and it turns out it can strafe sideways and spin on the spot — full holonomic motion — none of which is in any documentation I could find. The SDK just exposes a pile of motion codes with vague names, and the only way to learn what each actually did was to fire it at the real robot and watch. So I did: send code 3, it spins left on the spot; code 10, it slides sideways a metre and a half without rotating. Watching a service humanoid crab across the room when you had no idea it could is a proper “wait, it can do that?” moment.

I wrote the whole thing down — which code does what, plus the gotchas (the “turn” codes are actually orbits, not on-the-spot spins, and read reversed) — so the next person, probably future me, doesn’t have to rediscover it. The driver itself is still in development, but the hard part — knowing what the robot can actually do — is mapped. A robot is often far more capable than its own manual admits.

Honest scorecard

  • Sanbot ROS2 driver + holonomic discovery — ✅ driver built; omni motion (strafe/spin) mapped and documented.
  • Wheelchair robot — ✅ built and hardware-verified, way past plan.
  • TurtleBot2 SLAM + nav — ✅ mapping and navigating, with a clear-eyed view of the depth-cam limits.
  • PiBob ROS2 — ✅ done, real servos driven from RViz.
  • Heterogeneous fleet driver — safety-hardened, getting more solid each month.
  • Meta Quest teleop for PiBob / Inmoov — ❌ built but could be better, not fully tested with the Inmoov
  • Burf Platform improvements — Security fixes and simple SLAM / A* navigation added to Burf Platform

What’s next

First job is getting the wheelchair onto ROS2: sensors properly mounted, a URDF built from the real mounting positions, laser-odometry and slam_toolbox, so a driven journey turns into a live 2-D map in the browser. Drive it around a room, watch the map appear — that’s the satisfying full-circle moment. Then the fun part: run all that recorded trip data through some AI — every run captures LiDAR, IMU, GPS, and camera, and all that data is begging to be learned from rather than just replayed.

Alongside that, two longer threads. Keep building out the platform that ties these very different robots together — more of the control, telemetry, and fleet features that make a pile of one-off robots behave like one system. And keep levelling up my ROS2, which every one of these builds quietly pushes a bit further.

For a part-time evenings-and-weekends operation, June was a good month: four very different robots, all moving, all talking through the same stack. That’s exactly the direction I wanted this to go. More next month.

May 2026: The Platform Takes Shape

Posted on by burf2000

Hello and welcome to another Burf Update. Two months have passed since my last post, and for once I can say the gap is because I’ve actually been building things rather than just thinking about them.

Burf Platform
Back in March, I admitted I hadn’t properly defined what the Platform was or what problem it solved. Well, that’s changed — and it’s been the main focus of the last two months.

The headline is BRemote — a unified app now covering four robots across two platforms. The Android app supports Sanbot, Afobot, and iPAL from a single codebase, and the iOS app brings the Double 2 into the fold. Getting iPAL working was a pleasant surprise given how locked down it can be — Sanbot control is working really well, Afobot is solid with some minor turning quirks still to iron out, and iPAL has a working camera feed with full control coming next.

Beyond the apps, the Platform API is now properly working — WebRTC video feeds running across all robots with data recording, telemetry, and commands consistently across the fleet. It’s starting to feel like a real product rather than a collection of separate experiments, which is a good feeling.

PiBob
PiBob has been open-sourced — the aim was always to make it as accessible as possible, and this feels like the right move. ROS2 support is on the roadmap, but right now the Platform is the priority.

Viam Rover
The Viam rover is up and running, auto-connecting to the Viam cloud on startup. I’ve already built a Burf Platform driver for it, so it sits alongside the other robots in the dashboard. More time is needed to properly put it through its paces, but the integration is there.

UGV
Back up and running after the Cube Black USB port issue was resolved. Had a brief play but nothing dramatic to report yet — it’s a capable machine that deserves more focused time than I’ve given it.

Hack24
Still parked. One day!

InMoov
Nothing to report this month. The Platform is where the energy is going right now, and that feels like the right call.

Brilliant
Still going daily and at 533 days now. One of those habits that just keeps rolling.

Plan for 2026 — honest scorecard:

  • Strengthen Burf Robotics — progressing
  • Launch Burf Platform as MVP — BRemote unified across four robots and two platforms, API working, data recording underway. (Strong progress)
  • Continue learning ROS2 — PiBob driver on the roadmap. (Progressing)
  • InMoov Robots — Still quiet. (Needs attention)
  • Continue Brilliant learning — Daily streak continues. (Ongoing)
  • Build my own robot product — PiBob open-sourced. (Progressing)

For the first time in a few months, the plan actually feels like it’s moving in the right direction. The Platform has a clear identity, BRemote has a consistent name across both platforms, and the focus is on holding. Let’s see if I can say the same thing next month.

March 2026: The Robot Edition

Posted on by burf2000

Hello and welcome to another Burf Update. So, as usual, my ability to focus on a single thing has gone Pete Tong. In the last edition, I was set on getting the Platform out there and seeing if it has legs. Instead, I purchased some new toys!

iPAL Humanoid Companion Robot
The first interesting addition to my robot collection is the iPAL robot — slightly taller than a Sanbot, it’s a super cute, child-like robot. It has working arms, though the fingers aren’t powered. It runs Android 7 and they’ve done a solid job with the software — the head tracking is a nice touch and the voice is surprisingly cute. I believe they still sell them, and it even comes with a ROS driver, which I’m looking forward to exploring.

Unmanned Ground Vehicle (UGV)
This large, monster truck-like robot was an interesting eBay find — clearly someone put serious money into building it. It runs the Herelink system with a CubePilot Cube Black brain, and comes equipped with GPS (Here2), Lidar, and a camera system. From the Android-powered controller you can send it GPS waypoints and off it goes autonomously. It’s a new area of robotics for me and I’m looking forward to spending more time with it.

PiBob Desktop Robot
I also built a desktop robot called PiBob. The aim was to design something fun that was as cheap and simple to build as possible — and it was great fun to make. It’s powered by a Raspberry Pi 3 (had one lying around) and a servo shield, using affordable servos that keep the total build cost under £100 excluding the Pi. It’s still early stages, but I’m hoping to expand it into a larger, moving version.


The Platform
Not much progress on the Platform this month — I’ve been trying to find the headspace to properly define the MVP and the problem it actually solves. The current robot support list, outside of the ROS 2 driver, is fairly limited and a little dated. Once I’ve got clarity on the direction, I can move it forward with more purpose.


Tarot FY680 Heavy Lift Autonomous Drone
I bought this drone a few months back, but have never tried to fly it — out of pure fear. If this thing hits you or falls out of the sky, you’re going to get seriously hurt. It’s 1 meter tip to tip and can lift up to 7 kg. I’ve just completed my FlyerId and OperatorId, so I can now legally fly it, and my first flight was a brave 1 meter off the ground.

Burf Robotics
Not much progress this month — I’ve had a couple of chats with other companies, but I still haven’t actively gone out and marketed it. People have been coming to me, which is encouraging, but I need to change that dynamic.

ROS2
I’m continuously using ROS 2 but need dedicated time to expand my knowledge. This month I’ve been more focused on OLO consultancy work, which has come at the expense of learning. I need to prioritise this.

Brilliant
Continuing daily and at 479 days now. Like ROS 2, I need to push myself out of my comfort zone with it — or decide to drop it.

Hack24
Parked until I have time to properly test it.

Meta Quest Tracking
I spent a little time on this to see if it works with PiBob. The results were underwhelming, so it needs more attention before it’s useful.

InMoov Humanoid Robot
Nothing to report this month — and honestly, writing this blog has made it clear just how much I’ve lost focus. That needs to change.

Plan for 2026
The plan isn’t exactly going to plan — a lot of the goals above haven’t moved forward, but I did redirect my time towards some shiny new things instead.

  • Strengthen Burf Robotics and its offerings
    Target: Gain at least one additional customer. (Progressing)
  • Launch Burf Platform as an MVP
    Target: Deliver an MVP with user management, robot management, and support for a range of robot platforms. (Done)
  • Continue learning ROS2
    Target: Deepen my understanding of Nav2, MoveIt, and integrating AI with ROS2. (Needs more progress)
  • Inmoov Robots
    Target: Focus more on interactive demonstrations rather than building additional robots. I’d still like to develop a mobile InMoov platform. (Needs more progress)
  • Continue Brilliant learning
    (Needs more progress)
  • Build my own robot product
    Target: Not fully committed yet, but PiBob is a proof of concept and a step in that direction. (PiBob POC built)

Let’s be honest — I failed at formalising a plan this month. I’m going to sit with this blog post for a while and figure out what actually matters to me.

February 2026: The Platform Edition

Posted on by burf2000

Hello and welcome to another Burf Update. I have been super busy trying to get the first version of The Platform out to see if the idea has legs. Hopefully by next month I should know if it does.

The Platform
Formerly known as Burf Platform—a name that didn’t make much sense—the Platform is a robotics system designed to make it easy for users to teleoperate their robots. It is launching with ROS 2 support and also supports a range of other robots, including the Sanbot Elf, Double 2, and even the InMoov humanoid robot.

The goal is to contribute something meaningful to the field of robotics. There are plans to expand support to additional robot types, with a particular focus on helping hobbyists, supporting drones, and enabling data collection. A fully functional API is already available.

Burf Robotics
The goal is to continue to build the brand and client base. I have already had some positive talks with other robotics companies this month. I still have the lust to build my own robot, however The Platform is my current focus.

ROS2
I am continuously using ROS 2; however I need some focus time on expanding my knowledge. I have been focused on The Platform, and that needed limited ROS 2 functionality. I need to get back to the Udemy courses that I had started a while back.

I have started work on a PiCar ROS 2 driver (Ackermann-steering), and I have updated my TurtleBot2 to ROS 2, and it is now running a Jetson Nano instead of the Jetson TK1. I also purchased a VIAM robotic rover to try out.

Brilliant
Continuing daily and at 443 days now. Like ROS 2, I need to take myself out of my comfort zone.

Hack24
A blast from the past, Hack24 was one of my favorite game projects that I built over 10 years ago. Well, I decided to chuck the old Objective-C OpenGL code base at Claude and see if it could rewrite it in Swift using SceneKit, and I have to say, it did a good job. The server has been rewritten in Swift Vapor, as I need to focus on learning Swift again. I hope to release it pretty soon as a bit of fun.

Meta Quest Tracking
I have also started working on a Meta Quest 3 app to track body movement. This is to replace the Apple Vision Pro demo I had controlling the Inmoov Humanoid Robot, as I do not have access to the AVP anymore.

InMoov Humanoid Robot
I did have a brief play with one of my InMoov’s recently. The SD card in one of the Raspberry Pi’s had died, so I fixed that and ordered it a sound card and mic. I hope to use this with the tracking app very soon

Plan for 2026
The last month has been super busy, so yet again I find myself running before I have properly thought about the year’s goals. However, let’s see if there is any progress from last month.

  • Strengthen Burf Robotics and its offerings
    Target: Gain at least one additional customer. (Progressing)
  • Launch Burf Platform as an MVP
    Target: Deliver an MVP with user management, robot management, and support for a range of robot platforms. (Done)
  • Continue learning ROS2
    Target: Deepen my understanding of Nav2, MoveIt, and integrating AI with ROS2. (Needs more progress)
  • Inmoov Robots
    Target: Focus more on interactive demonstrations rather than building additional robots. I would still like to develop a mobile InMoov platform. (Progressing)
  • Continue Brilliant learning
  • Build my own robot product
    I am not fully committed to this yet; however, I did begin building my own robotic arm. Developing my own robot could be a valuable learning experience, particularly by designing and implementing the ROS2 drivers around custom hardware. This would focus on a robotic system with arms rather than a mobile platform. (Needs refining)

Hopefully, next month’s edition, I will actually finish formalising a plan.

January 2026: Happy New Year Edition

Posted on by burf2000

Hello and welcome to another Burf Update. I hope everyone had an amazing Christmas and an epic New Year. The Christmas period rushed through at lightning speed, but was enjoyable. In this edition, I hope to map out what I plan to do in 2026.

Burf Robotics
Burf Robotics is the key focus for 2026 in that I want to make sure it is properly operating as a company now that it has its first customer (OLO Robotics), which moves it from an idea to a reality. I am also working on its first product Burf Platform.

Burf Platform
Over the festive period, I spent much of my spare time working on the platform. The current vision remains a remote teleoperation platform that supports multiple types of robots. So far, I have developed drivers for:

  • Sanbot Elf
  • Afobot
  • ROS2 Mobile robots
  • Double 2 Robot

The ROS2 driver is the one I am most excited about, as it has the potential to open access to a wide range of robots. My aim is to make integrating the driver as simple as possible, mapping the camera feed (via WebRTC), sensors, and teleoperation topics directly into the platform. The next step is to set up hosting for the platform.

ANYCUBIC Photon Mono 4
So on a different note, I got a resin printer for Christmas, which was awesome. I am super impressed with the printing quality; however, it is a lot messier and smellier than normal 3D printing. I hope it will expand what I am able to print for my projects.

ROS2
I have continued my learning on ROS2, and I am really enjoying it. I still have an awful lot to learn. It feels the more I understand, the more I need to learn. However, for my needs, I am making good progress. I need to get back to the Inmoov ROS2 driver (Sim) I updated and then work on a hardware driver for that. I also want to take a look at Foxglove, which allows you to visualise all of your ROS data.

Brilliant
Something I had not mentioned for a while is that I am still doing Brilliant.org daily and am up to over 400 days now. I do need to actually focus on expanding my learning here instead of going for the easy topics.

Reviewing 2025
At the start of 2025, I set 3 high-level goals:

  • MyRobotLab + The Inmoov + LLM
  • ROS2 and the Rover Robot
  • Gwiz and predictive driving

The year didn’t go as planned due to my redundancy, but I ended up doing more robotics than in any previous year. This led to the formation of Burf Robotics, and I successfully met my MyRobotLab and ROS2 goals. The Gwiz was always intended as a fun side project, so I’m not concerned about that. My conservatory has now become a dedicated robotics space, and overall, I feel I’ve gained a significant amount of knowledge over the past year.

Plan for 2026
I haven’t fully stepped back to define the plan in its entirety yet; however, I do have several clear areas of focus for 2026:

  • Strengthen Burf Robotics and its offerings
    Target: Gain at least one additional customer.
  • Launch Burf Platform as an MVP
    Target: Deliver an MVP with user management, robot management, and support for a range of robot platforms.
  • Continue learning ROS2
    Target: Deepen my understanding of Nav2, MoveIt, and integrating AI with ROS2.
  • Inmoov Robots
    Target: Focus more on interactive demonstrations rather than building additional robots. I would still like to develop a mobile InMoov platform.
  • Continue Brilliant learning
  • Build my own robot product
    I am not fully committed to this yet; however, I did begin building my own robotic arm. Developing my own robot could be a valuable learning experience, particularly by designing and implementing the ROS2 drivers around custom hardware. This would focus on a robotic system with arms rather than a mobile platform.

In my next update, I hope to solidify the plan.

December 2025: Christmas Edition

Posted on by burf2000

Hello and welcome to another Burf Update, I hope everyone is enjoying the run up to Christmas and that special time off with loved ones. Around this time I start to work out what I have achieved this year.

OLO Robotics
Formally BOW, I am chuffed to announce that I am contracting for them 1 day a week (outside my day job) testing their robotics platform. This is through Burf Robotics which means it has it’s first customer. They have lent me a Leo Robot to put their platform through its paces which is a great bit of ROS2 kit. This proves that my learning with ROS2 and setting up Burf Robotics was a good idea and also keeps me doing robotics regularly .


ROS2 Rover
I have also made some improvements to the ROS2 3D Printed Rover I built. I have added an IMU (MPU 6050 instead of MPU9250 due to counterfeit parts) however this introduces me in to sensor fusion as you need to fuse the ODOM with the IMU data. I need to spend more time on this but it should improve the rover and my knowledge of ROS2.

Double Robotics 2
A bit of a random buy one night but I now have an old Double Robotics 2 robot. This is like a tele-presence robot with a an iPad on top. It is actually a nice bit of kit and I hope to add it to my Burf Platform as my first iOS Robot. Most of my other robotics run Android


Burf Platform
So I am working on a idea around having a platform that allows remote control of old / hobbiest robots for people who can’t program there own robots but still want to use them. It’s still early stages but I hope to have a prototype up soon similar to the remote control app for the Sanbot robot. I want to use this as a learning project to learn a new technology, just deciding on what that is.

Claude Code
So about a month ago I moved from Cursor (brief use) to Claude Code and am amazed on how powerful it is. I mean it can do so much more compared to Cursor and ChatGPT. I would say the limits on the it are very tight compared to Cursor, however it is still a game changer.

Reviewing the Plan

So here was the latest plan from September before I lost my job:

  • Create a Sanbot Remote Control App
  • Continue to deepen my ROS2 knowledge
  • Continue Developing the InMoov Humanoids
  • Have Fun with the G-Wiz

So the G-Wiz has been paused for the moment as it needs new batteries, isn’t taxed (No longer free to tax) or insured and so there is too much up front effort to fun ratio right now.

I have not done a great deal with the Inmoov Humanoids because (as I have just remembered) I started building my own simple arm, to later build a whole robot as I wanted something I could own myself. The Inmoov robotics are fantastic however they can not be used for commercial gain. I think I may get back to this, however also need to work on the 3rd Inmoov robot

I have continued to improve my ROS2 knowledge and the work with OLO Robotics can only help this. This also shows Burf Robotics has potential.

The Sanbot Remote app, which will extend to the Afobot robot and then later the Double robotics 2 robot, will become the Burf Platform (Name to change) which I have a lot of ideas for. After the OLO Robotics work, the Burf Platform will be my focus for a bit.

So on reflection, the last month has actually involved a lot more robotics than I expected after losing my job.

October 2025: All Change Edition

Posted on by burf2000

Hello and welcome to another Burf Update — this one’s a little different, and honestly, a bit sad. I can’t imagine there’ll be much robotics content in this one… but let’s see 🙂

Compsoft
Sadly, I (along with many others) have been made redundant from Compsoft. I’d just returned from my holiday when — boom — the news hit. It’s definitely a shock, though I understand the business has been struggling for some time.

I’ve spent around 18 years at Compsoft (with a few years away in between), and it’s been an amazing journey — great people, great projects, and so many memories.

Of course, this changes my future quite a bit. The job market feels chaotic compared to what I’m used to, but I’m incredibly thankful to say I’ve already been offered a new job, which I’ve accepted.

Burf Robotics
In the middle of all this, I wasn’t sure what the future would look like — but I’ve gone ahead and set up Burf Robotics Ltd!

It’s still early days, but I’m excited to see where it might go in the limited time I’ll have around my new role. Robotics has always been a passion, and this feels like a natural next step.y new job.

Milton Keynes Smart City and Robotics Competition
With all the Compsoft changes, the show we’d originally signed up for got re-themed as Burf Robotics — and we even made a brief appearance on the BBC, which was a nice surprise!

It’s been a rollercoaster, but I’m hopeful that new beginnings will come out of it all.

I also managed to get interviewed for a Robotics Podcast

Reviewing the Plan
Outside of all this, I’ve mainly been focused on finding a new role and training up for it.

Right now, the plan is simple: do a great job in my new position — that’s my top priority. After that, I’ll review which robotics projects I can realistically take on with the limited time I’ll have.

It’s a bit sad that after achieving so much this year with robotics, things have ended this way… but I’m determined that it won’t be the end of the journey. Just a pause — and maybe the start of something new.

September 2025: Head Down Edition

Posted on by burf2000

Hello and welcome to another Burf Update, I struggled for a bit to pick a title for this edition due to the range of robotic things I have done over the last month. I have certainly spent a lot of time doing robotics.

Gwiz Update
I have only spent a few hours on the Gwiz, I am trying to work out which batteries are still iffy. I have also installed a battery meter and a 10″ Android headunit which I hope to be able to deploy my own apps to. This allow me to record driving data etc.

Afobot
Back when I bought my 17 Sanbot Elf robots, I was also given 40 (ish) Afobot robots. These are little desktop based things with a screen that can move side to side and up and down. They run Android 7 and initial investigations seemed like they had no SDK and no real use. However with the help of ChatGPT, I managed to write some code to control the motors. Next plan is to connect it to my websockets project and support teleop.

ROS2, the Rover Robot and the Robotic Arms
So I have continued to learn ROS2, overcoming some headaches etc. I still need to learn more, however the knowledge is slowly sinking in. One awesome thing I did get going was simulating the Inmoov robot in Rviz2 and Gazebo. This was super cool but nearly broke my brain. A lot more work needs to be done but its a positive start.

I also built a setup so that I could place a LEGO brick and my robotic arm would pick it up (myCobot 280)

Inmoov Update
As for the Inmoov humanoid robots, I am preparing 2 of them for a show this Month. In preparing Robob, its arm snapped off which I have now rebuilt. Robob and Reggie both run off a Raspberry Pi 5 now and I am working on making them more portable. I have not done any more work on the 3rd robot, but do plan to.

Burf.co
So, I have turned off the Burf.co Search Engine for the moment to help me focus on the future which at the moment is robotics. I want to get my own teleop robotic service going and so need to focus. The site has also moved to faster hosting (Thanks Adrian).

Reviewing the Plan
I am super keen to focus on the plan I set out last month, so lets see if I have helped towards it, or as usual got sidetracked.

Create a Sanbot Remote Control App

  • Design a controller that streams all sensor data from the Sanbot to a user interface, allowing remote movement and activation of functions.

So I have created a prototype Android app and Python script that streams sensor data including camera to a server from a Sanbot. I can also move the robot and make it speak. Next I want to be able to support multiple robots and control head/arm movement.

Continue to deepen my ROS2 knowledge

  • Fix bugs around MyCobot280/xArm hardware, so that API works well
  • Finish self-driving course on Udemy
  • Understand SLAM and mapping better so that a robot can travel between rooms
  • Add IMU support

I have continued to increase my ROS2 knowledge and am progressing with the MyCobot Arm and the self driving course. For work I have written a cool script that can control the robotic arm to pickup a LEGO brick.

Continue Developing the InMoov Humanoids

  • Have an active one for improving Vision and LLM use. Think about using a Neural Net to give personality. Think about gestures.
  • Create a mobile Inmoov robot, even if its remote
  • Consider merging this with the Sanbot remote control app

At the moment, I am focusing on getting the Inmoov robots ready for a show, however in doing so I am improving them. With the ROS2 Inmoov work happening, this only improves my likelihood of doing more ROS2 and Inmoov work.

Have Fun with the G-Wiz

  • Design a remote-control system (concept-only for now)
  • Add sensors and record journey data
  • Use that data in a self-driving AI test
  • Explore ROS integration for car control

Some small steps made by adding the Android headunit, I have lots of ideas here but mainly focusing on the fun side.

It generally looks like I have stayed on track which is good news, I hope the October update shows equal or even more progress.