← ALL BLOGS & ARTICLES

/ TECHGEEKS OPEN SAUCE

Why the PCB Is the Chassis: Inside the Techgeeks Spirit Design

Why the PCB Is the Chassis: Inside the Techgeeks Spirit Design

The Spirit skips the separate frame entirely and lets one PCB carry the motors, the impeller, and every electronic component. Here's the engineering logic behind that decision, and the stiffness-for-modularity trade it makes along the way.

BRAINSTORMING

/ METADATA

DATE:

AUTHOR:

Hrithik Khanna

READING:

8 min read

View Related Product

SPIRIT PCB CUM CHASSIS CONCEPT SCIENCE BLOG TECHGEEKS THUMBNAIL

Most line followers stack layers to get to the track: a 3D-printed chassis, standoffs, a separate controller board bolted on top, then sensor and motor mounts fastened to whatever's left.

Every one of those joints is a place the frame can flex. Every layer is height added to the center of mass, right when a suction bot needs to stay low and press down, not wobble.

The Spirit removes the stack. The PCB itself is the frame: motor mounts, impeller housing, and sensor connector all live on one board, with nothing bolted between them and the track. Here's what that decision actually changes, from the power rails up through the firmware.

If you're deciding between the two Spirit driver variants as you read this, Techgeeks' community has other builders comparing their own Model 1 and Model 2 builds worth a look before you commit.

The stack a normal LFR carries, and what Spirit removes

A conventional suction LFR mounts its controller board on standoffs above a separate chassis plate, then bolts on motor brackets, a sensor arm, and an impeller housing as their own parts. Each fastener is a tolerance stack: a little play in four joints becomes real flex once the bot is cornering at speed.

The Spirit collapses all of it into one PCB. The Arduino Nano socket, both motor driver footprints, the impeller housing, and the sensor connector are all traces and pads on the same board. Motor mounts attach directly to the PCB's edge cutouts. There is no frame underneath it to bolt to, because the board is the frame.

Every joint removed from the stack is a joint that can no longer flex under load.

An airframe shaped around one part: the impeller

The PCB's outline isn't a rectangle with corners rounded off for looks. It's cut specifically to put the impeller at the board's geometric center, so the downforce it generates pulls evenly rather than tipping the nose or tail. The same outline balances mass between the two motor mounts on either side.

The board itself measures 72mm by 120mm and carries the entire drivetrain and downforce system. A complete Model 2 build (TB6612FNG driver, N20 motors) lands around 120 grams; Model 1 (dual DRV8874 drivers, coreless motors) lands around 140 grams, with most of that difference coming from the higher-current driver hardware, not the board itself.

At operating speed with the vacuum skirt properly seated, that airframe generates over 700 grams of active downforce, pressing a 120 to 140 gram robot onto the track with 5 to 6 times its own weight.

The outline is a load path and a weight-distribution decision, not a styling choice.

Two power rails, kept deliberately apart

The Spirit splits power into two independent rails: a logic and sensor rail on the left, and an impeller rail on the right. Each rail draws from exactly one source, either an onboard solder pad you bridge or a dedicated 5V 3A BEC (battery eliminator circuit), and the manual is explicit that mixing both on the same rail can damage the board.

The reason to keep them apart is current. The impeller's 8520 coreless motor can pull close to 2A at peak, and if that current shared a rail with the sensor array or the Nano's logic supply, voltage sag under load could show up as sensor noise or a brownout exactly when the bot needs its cleanest read: mid-corner, at full downforce.

The logic rail's own threshold is concrete. Short the pad and draw straight from the Nano's 5V pin, comfortable up to roughly 300mA. Past that, the manual calls for the dedicated BEC instead, because the Nano's onboard regulator starts to strain.

Isolating the rails isn't caution for its own sake. It's the only way to keep a 2A impeller draw from ever touching a sensor signal.

Why the impeller runs on a register, not analogWrite()

Both Spirit variants drive the impeller's PWM (pulse-width modulation, how the speed controller sets average power) through direct Timer2 register access rather than Arduino's analogWrite(), configured for 62.5kHz with no prescaler instead of the roughly 490Hz analogWrite() gives you by default on that timer.

The 8520 impeller motor is coreless: no iron core in the rotor to buffer heat or smooth out current ripple in the winding. At 490Hz, that ripple is audible as coil whine and wastes energy switching. At 62.5kHz, the switching disappears from hearing range and the current through the coil stays close to steady.

A motor with no iron core to smooth things out needs the switching frequency to do that job instead.

One board, two different relationships with three timers

Model 1, running dual DRV8874 drivers for coreless motors, has a collision: Motor A's PWM lands on D3, which shares Timer2 with the impeller's PWM on D11. That collision is why Model 1's entire firmware uses direct register access, not just for the impeller. Mixing analogWrite() on D3 with a manually configured Timer2 would corrupt the impeller's own timing. Motor B, on D9's Timer1, gets the same register-level treatment for consistency, even though nothing forces that choice.

Model 2, running a single TB6612FNG for N20 motors, has no collision at all. Motor A sits on Timer0 (D5), Motor B on Timer1 (D10), and the impeller alone on Timer2 (D11). Three separate timers mean Model 2's drive motors run on ordinary analogWrite() and digitalWrite(), while only the impeller keeps its manual 62.5kHz setup, for the same coreless-motor reason as Model 1.

Choosing between Model 1 and Model 2 is really choosing between two different relationships with the ATmega328P's three hardware timers, not just a driver chip preference.

What a monolithic board buys you, and what it costs you

The gains are the ones the airframe was built for: lower mass, a lower center of gravity, more rigidity per gram, and fewer fasteners to work loose over a season of runs.

The cost is repairability. Crack a motor mount tab on a modular chassis and you print a new plate. Crack the same feature on the Spirit and you're looking at the same board that carries your Nano, your drivers, and your impeller controller. That isn't a flaw the design hides. It's the trade a monolithic airframe makes on purpose, in exchange for the stiffness and mass numbers above.

Conclusion

Every decision in the Spirit traces back to one choice: remove every layer between the impeller and the track, and let the board itself carry the load. The power rail split, the register-level PWM, and the timer allocation on both models all follow from that single starting constraint.

If you're designing your own board next, the real question the Spirit answers is this: what would you remove from your own stack if the board itself could carry the load?

The two variants, and the full pin-level manual behind this breakdown, are on the Spirit product page. Build either one, and the community linked above is exactly where to post what you find when you push it past what the manual covers.

Done reading? Return to the field notes index or keep exploring TechGeeks robotics parts.