From PCB to Field Robot: What Designing a Custom Controller Board Looks Like

TL;DR: Designing a custom robot controller board for a field UGV is less about picking the fanciest MCU and more about reconciling competing constraints: motor current, ROS/ROS 2 integration, EMI, mechanical footprint, and a BOM that survives component shortages. This article walks through how Fictionlab approached LeoCore, the controller board powering the Leo Rover: what the requirements looked like, which iterations failed, what was learned about firmware-hardware co-design, and why the schematics ended up open source.

Why Build a Custom Robot Controller Board at All?

The first question Fictionlab’s team asks on any new platform is whether an off-the-shelf board would do the job. For a hobby differential drive, the answer is usually yes. For a field robot that has to survive outdoor temperature swings, vibration, muddy connectors, and integration with a ROS/ROS 2 stack running on a Raspberry Pi, the answer becomes more nuanced.

A generic motor controller solves the “spin the motors” problem. It rarely solves the system problem: clean power distribution to a single-board computer, user-accessible GPIO for payloads, encoder feedback synchronized with the control loop, IMU integration, firmware that exposes a stable interface to the ROS stack, and a connector layout that matches the chassis. Every one of those gaps becomes an extra PCB, an extra cable harness, and an extra failure mode in the field.

That is the trade-off that pushed the Leo Rover toward a custom robot controller board. Consolidating those functions into one PCB reduces wiring, simplifies firmware updates, and lets the mechanical and electrical designs evolve together.

What Requirements Drove the LeoCore Design?

Before any schematic capture, the team wrote down what the board actually had to do. The list ended up looking like this:

• Drive four brushed DC motors with current sensing, suitable for the Leo Rover’s skid-steer drivetrain.
• Read quadrature encoders from each wheel with enough resolution for closed-loop velocity control.
• Provide regulated 5 V at sufficient current for a Raspberry Pi 4 plus camera and accessories.
• Expose user-accessible GPIO, I2C, UART, and servo headers for payloads such as manipulators or extra sensors.
• Integrate an IMU on-board to avoid a separate sensor module.
• Communicate with the host SBC over a single reliable link, with firmware that maps cleanly to ROS/ROS 2 topics.
• Survive the input voltage range of a 3S Li-Ion pack, including the messy transients of a brushed motor under load.

That last point is deceptively important. A custom robot controller board for a mobile platform lives downstream of brushed motors that generate ugly noise on the supply rail every time they reverse direction. Much of the EMI work on LeoCore came from taking that seriously early.

How Did the First Iterations Go Wrong?

The first prototype validated the architecture and broke in interesting ways. A few of the lessons that stuck with the team:

Power Stage Realities

The initial H-bridge selection looked fine on the datasheet. In practice, stall currents during outdoor testing pushed the drivers closer to their thermal limits than the team was comfortable with. The fix was not just a bigger driver. It was rethinking the copper pour around the power stage, adding thermal vias under the package, and reworking the placement so that heat from the bridges did not creep toward the IMU and bias its readings.

Ground Loops and Encoder Noise

On one revision, the encoder signals picked up enough noise from the motor leads that the velocity estimate jittered noticeably at low speeds. The cause was a classic shared-impedance problem between the motor return path and the logic ground reference. Separating the high-current return paths from sensitive logic references, with a controlled connection and routing motor returns away from signal lines, fixed it. This is the kind of problem you only catch when the board is bolted into a real chassis with real cable lengths, not on a bench.

Connector Choices

Early prototypes used connectors that were convenient on the bench and miserable in the field. Vibration loosened a few, and one variant was difficult to mate blindly when the board was already installed in the chassis. Later revisions standardized on locking connectors with clear keying, which is unglamorous work that pays off every time a user services the robot.

Firmware-Hardware Mismatch

One revision shipped with a peripheral pin assignment that looked sensible in the schematic but forced the firmware into an awkward DMA configuration. The control loop worked, but adding new features later became painful. The lesson, repeated in every hardware project ever: have the firmware engineer review the pinout before the board goes to fabrication. A thirty-minute review saves a month of workarounds.

How Does the Board Talk to ROS 2?

A custom robot controller board is only as useful as its software interface. LeoCore exposes its state to the Raspberry Pi running the ROS stack through a serial link, with firmware that streams wheel odometry, IMU data, battery voltage, and accepts velocity commands. On the SBC side, a ROS/ROS 2 node translates this into standard topics like /cmd_vel, /odom, and /imu/data_raw.

The design choice worth highlighting: the board does the real-time work, and the SBC does everything else. The motor control loop, encoder counting, and IMU sampling all happen on the microcontroller, where timing is predictable. Navigation, perception, and higher-level logic stay in ROS/ROS 2 on Linux, where timing is not predictable but compute is abundant. This split is standard practice in field robotics for good reason, and it kept the LeoCore firmware small enough to be maintainable.

Why Open Source the Hardware?

The schematics, PCB layout, and firmware for LeoCore are published openly. There are a few practical reasons behind that decision.

Researchers and integrators who buy a Leo Rover often want to modify it. Knowing exactly what is on the controller board, which pins are exposed, and how the firmware handles edge cases makes integration faster and less risky. When a customer asks whether a particular sensor can be wired into a spare UART, the answer is in a repository they can read, not in an email thread.

Open hardware also creates a feedback loop. Users can spot issues, suggest improvements, and contribute firmware patches. For a small team, that external review is genuinely useful. It is also how Fictionlab’s custom robotics projects benefit: lessons from the open platform feed back into bespoke designs for clients who need something the standard Leo Rover or Raph Rover does not cover out of the box.

What Carries Over to Larger Platforms?

Designing LeoCore gave the team a template for thinking about controller electronics on bigger machines. The Raph Rover, a heavier platform aimed at more demanding field work, did not reuse the LeoCore board directly, but it inherited the design philosophy: consolidate functions, plan for EMI early, keep the real-time work close to the motors, and treat connectors as a first-class design concern.

The patterns that transfer between platforms include separating power and signal return paths with intent, putting current sensing on every motor channel because debugging without it is painful, exposing more GPIO than seems necessary because users will always want one more, and writing firmware against a clear ROS/ROS 2 contract from day one.

What Does the Process Look Like End to End?

For anyone considering a similar project, the rough sequence Fictionlab follows is straightforward, though each step contains its own rabbit holes:

1. Write down the system requirements, including mechanical and thermal constraints, not just electrical ones.
2. Sketch the block diagram and validate the architecture against the ROS/ROS 2 software stack that will run on the SBC.
3. Select critical components (MCU, motor drivers, regulators, IMU) and check availability across multiple distributors.
4. Draft the schematic, then have someone other than the author review it.
5. Lay out the PCB with placement driven by power flow and thermal paths, not by what looks tidy.
6. Build a small prototype batch, instrument it, and run it in a real chassis under real load.
7. Iterate. Expect at least two or three board revisions before the design is field-ready.
8. Document everything, because the version of you who debugs this in eighteen months will not remember why a particular resistor is there.

None of this is exotic. It is just disciplined engineering, applied with the knowledge that a field robot’s controller board will be judged by how it behaves in mud and dust, not on a bench.

FAQ

Q: How long does it typically take to design a custom robot controller board from scratch?

A: For a board of LeoCore’s complexity, expect several months from requirements to a field-ready revision, assuming an experienced team and at least two prototype iterations. Component lead times can extend this considerably.

Q: Can a generic motor driver replace a custom controller in a field robot?

A: For simple indoor experiments, often yes. For outdoor UGVs that need integrated power distribution, encoder feedback, IMU data, and a stable ROS/ROS 2 interface, the wiring complexity and failure surface usually justify a consolidated board.

Q: Why use a microcontroller for motor control instead of doing it on the SBC?

A: Standard Linux on a Raspberry Pi cannot guarantee the timing required for a tight motor control loop. A microcontroller handles real-time tasks deterministically, while the SBC handles ROS/ROS 2, navigation, and perception where occasional latency is acceptable.

Q: What is the most common mistake in first-time controller board designs?

A: Underestimating EMI from brushed motors and treating all ground return paths as if they were equivalent. Both lead to noisy sensor data that only appears under real load, not during bench testing.

Q: Are the LeoCore schematics actually usable as a reference for other projects?

A: Yes. They are published openly and can be used as a starting point by integrators building variants. The firmware repository is similarly open, which makes adapting the design to a different chassis or motor configuration more practical.

Q: How is firmware updated on a deployed Leo Rover?

A: The microcontroller firmware can be flashed through the onboard Raspberry Pi using the supported update tools, so a field update does not require disassembling the robot or attaching a programmer directly to the board.

Q: Does Fictionlab design custom controller boards for clients?

A: Yes. Custom electronics, including controller boards tailored to specific drivetrains, sensor payloads, or environmental requirements, are part of the custom robotics work the team takes on.

Need a Controller Board Built Around Your Robot?

If your project needs electronics that an off-the-shelf board cannot cover, Fictionlab’s team can help design a custom robot controller board around your drivetrain, sensors, and ROS/ROS 2 stack. Learn more about the custom robotics services and how the process works in practice.