pi-bot

pi-bot brings together a ground rover, a conversational agent and the software between them. I’m interested in the whole interaction: how it understands a request, what it is allowed to do, and whether the movement on the floor matches the intention.

The build combines Raspberry Pi and ESP32 hardware with ROS 2 navigation components and a Python capability layer. Separate extensions handle local-model integration, personality and connections to agent tools. Some of those pieces are useful without the robot.

The rover drives, uses lidar-based navigation and exposes tools to an agent. Named-place navigation and hardware bench work have exercised the connection between software intent and physical motion.

The complete interaction is still in progress. Live agent driving has exposed mistakes in direction and motion arguments, including confident descriptions of actions that did not match what happened. Voice and per-call identity integration also have work remaining. These are part of the build, not details I want to hide behind a demo.

Wheel encoders tell you how far the wheels turned. On a skid-steer rover, that is not always how far the body moved. We had spent considerable effort adding corrections around navigation estimates that were biased by wheel slip.

I stepped back and questioned why that measurement was still carrying the position estimate. The robot already had lidar. Translation moved to lidar scan matching, while the encoders kept their useful jobs in motor control and motion diagnostics.

The next physical test exposed another assumption: the lidar and heading estimates were using different reference directions. Earlier checks could look good without noticing that rotation. A measured drive on the floor made the mismatch clear, and we revised how the estimates were combined.

Another experiment tried to correct accumulated position error by matching a fresh lidar scan against a stored scan at a known place. It worked in synthetic rooms.

In the real room, a confident but incorrect match shifted the robot’s reference frame. That moved where it thought the goal was, and subsequent corrections compounded the error. Furniture, occlusion and similar-looking geometry exposed what the test rooms had missed.

I chose to disable the automatic correction. Manual re-anchoring remained available, and the remaining drift was within the tolerance we had set for that stage. I recorded the failure and the reasoning in the architecture decision, linked the issue to the code change, and kept the experimental kernel separate from the active path.

I want the robot’s character to be adjustable without making its authority adjustable by conversation. Recognizing someone can help it choose how to speak to them; it should not automatically give that person permission to drive it.

The design separates persona from the capability gate and separates that gate from physical motor control. It also provides a supervisor stop path that does not depend on the agent continuing to behave correctly.

The distinction is designed and partly implemented, but the live identity path is not complete. Calls still use a fixed operator identity while the per-call provenance integration is being built.

I make the architectural calls, work on the hardware and test the rover in the room. Coding agents help with implementation, tests and documentation. Established components such as Nav2 and robot_localization sit alongside project-specific control and verification code.

When a decision changes, I keep the earlier reasoning and add what changed it. Issues track the remaining work and physical checks; architecture records explain the choices that affect several parts of the system. Session briefings carry the current state into the next session.