Reference Designs

Reference Designs

Tested starting points for commercial boards and kits, with every pin, motor constant, sensor and Nav2 limit filled in. A design is a template for your robot, not a robot you switch to:

1. Name your robot in the web UI header's Robot field. Its config, <name>_config.yaml in ~/linorobot2-config/, is created then, and from then on every selection and every action you make updates it.
2. Pick a design under Reference Designs on MCU & Sim (tab 1). The design's controller side becomes your robot's: the MCU, board, pins, motor driver, sensors, micro-ROS link and LiDAR wiring. Your chassis stays: wheels, motors, kinematics and your Nav2 tuning. A freshly named robot has no chassis of its own yet and takes the design's.
3. Tune it. The robot is yours; the design only gave it a start.

A kit brings its own chassis. The SparkFun XRP, the Maker's Pet mini, and the Arduino UNO Q and Pico 2 mecanum (both on the MC200 mecanum chassis) come with their motors, wheels and body, so picking one brings those in as well. If your motors or wheels differ, change them afterwards on Base (tab 2) and Drive & Motors (tab 3). The other designs are controller boards only.

A robot built from a design is a real robot. It simulates nothing: every simulation toggle is off, and it runs in Real mode only (the cockpit refuses Sim mode and the Sim MCU for it). Flash, 🚀 Start 1-Click and Bringup need its own board and are refused without it. With No design picked and no pin assigned, your robot is a bare module of the board that is plugged in, with every device simulated: that is how to try the stack before anything is wired. A bare module has no pin assigned but the onboard LED. Assign one (a motor, an encoder, I2C, the battery) and it is a real robot like a design-based one: its simulated devices are turned off, and its board is needed. ↩ Back to a bare module takes it back, every pin unassigned. The Sim MCU robot (bare_sim) runs with no board at all.

The 1-Click flashes the matching release image and writes your robot's wiring into the env block.

Building from a reference design, step by step

The same order for every design. The bare module comes first, the design second, then the robot is built one subsystem at a time, each proved by its own tool:

1. Run the board as a bare module, in simulation mode. Plug the board in alone, keep No design, and press 🚀 Start 1-Click (step 2). Every device is simulated and no pin is assigned, so nothing can be driven or damaged; what you prove is the board, its link and micro-ROS. A bare module has no I2C pins and simulates its wheels and battery, so the tool's i2c finds no bus and its drive and battery commands are refused here: there is nothing real for them to test yet.
2. Name your robot and select its reference design on MCU & Sim (tab 1). The design brings the board's real wiring: its I2C bus and its motor, encoder, battery and LiDAR pins. The robot is real from here on (🔧 Real), and the tools that test its hardware are enabled. A Wi-Fi design (an ESP32 or ESP32-S3 on udp4, such as the Maker's Pet mini, whose design also has no I2C) needs the Wi-Fi keys in the Secrets tool tab before any flash: the first flash gives the board its network, and it is refused without them ([NO WI-FI KEYS]). The bare module before it ran over USB serial and needed none.
3. Build it up, one subsystem at a time (Building a Real Robot, from step 4): in the tool on Hardware Tests (tab 6), i2c and sensors for the I2C sensors, motor, motors and enc for the motors and encoders, adc for the battery (ESP32), and acc on the floor once the chassis is assembled; then the LiDAR, the first bringup and teleop, the speed check against the LiDAR, and SLAM and Nav2.
4. A Wi-Fi design (an ESP32 or ESP32-S3 on udp4) is flashed over USB once and then leaves the cable: the tools, bringup, teleop, SLAM and Nav2 all run over Wi-Fi, and every later write goes over the air. See A Wi-Fi robot leaves the cable.

Each design has its own page with its pins and a step-by-step setup; most also have a photo, a wiring diagram and a parts list:

Design	Drivetrain	MCU	Motor driver	IMU	LiDAR	micro-ROS link	Firmware image	Config	On real hardware
Waveshare General Driver	2WD	ESP32	TB6612FNG, driven two-PWM	QMI8658 + AK09918 mag	LD19 via LIDAR_RXD	USB serial (CP2102N, 1.5 Mbaud) or Wi-Fi	esp32-<distro>	gendrv_config.yaml	✅ bench board, serial and Wi-Fi
Yahboom YB-EET01 V2.0	4WD skid steer	ESP32-S3	AT8236	ICM-42670-P	MS200 (bundled) or LD19 on MCU UART1	Wi-Fi (udp4); USB (CP2102, console: uart0) for the first flash	esp32s3-<distro>	yb_eet01_config.yaml	✅ bench board, Nav2 over Wi-Fi
Pico 2 Mecanum	4WD mecanum, MC200 kit	Pico 2 (RP2350)	4 × AT8236	ICM-20948 (9-axis)	LD19 on the robot computer's USB	USB serial	pico2-<distro>	pico2_mecanum_config.yaml	⬜ config builds; the robot has not run it yet
SparkFun XRP Kit	2WD	XRP Controller (RP2350B)	DRV8411A	LSM6DSOX	LD19 on the robot computer's USB	USB serial	pico2-<distro> + XRP env	xrp_config.yaml	⬜ flashed on a real XRP Controller; topics and IMU pass, motors not yet driven
Arduino UNO Q	4WD mecanum, MC200 kit	UNO Q's STM32U585, on Zephyr	2 × AT8236 (driver_type: AT8236, the two-PWM scheme)	Qwiic, AUTO: Modulino Movement (LSM6DSOX) or BNO085	LD19 on the MCU (D0), sent as raw_scan	The board's internal UART, 4 Mbaud	unoq-<distro>, flashed over SWD by the 1-Click	unoq_config.yaml	✅ Nav2/SLAM on a real MC200 with a real LD19; speeds checked against the LiDAR
Maker's Pet Mini	2WD	ESP32	BDC-30P	none	LD14P on the MCU, over Wi-Fi	Wi-Fi (udp4)	esp32-<distro> + kit env	makerspet_mini_config.yaml	⬜ vendor config; kit not yet run
NULLLAB Maker-ESP32 PRO	4WD mecanum or skid steer	ESP32	4 × RZ7889	none	LD19 on the robot computer's USB	USB serial (CH340G); syslog and OTA only on the Wi-Fi transport (udp4)	esp32-<distro>	nulllab_esp32_pro_config.yaml	⬜ vendor documentation; not yet run
Pimoroni Motor 2040	4WD mecanum or skid steer	Pico (RP2040)	2 × DRV8833	none	LD19 on the robot computer's USB	USB serial	pico-<distro>	pimoroni_motor2040_config.yaml	⬜ vendor documentation; not yet run
Cytron Maker Pi RP2040	2WD	Pico (RP2040)	MX1508	none	LD19 on the robot computer's USB	USB serial	pico-<distro>	cytron_maker_pi_rp2040_config.yaml	⬜ vendor documentation; not yet run

Between them the designs cover all three drivetrains. Change one with the Base tab's drivetrain field; saving re-derives the Nav2 limits for it (unless kinematics.auto_nav2_limits is false). <distro> is jazzy or lyrical. Before anything is wired, run your robot with No design: a bare module of the board in simulation mode. For a board that is not listed, start from the bare module of its MCU and fill in the pin matrix.

---

At a glance

Pico 2 Mecanum	Arduino UNO Q	SparkFun XRP
Waveshare General Driver	Yahboom YB-EET01	Maker's Pet Mini
Cytron Maker Pi RP2040

_{Photo credits are on each design's page. The Yahboom board is shown by its wiring diagram; its maker publishes no photo under a licence this wiki can use.}

---

Choosing parts for your own build

• Motor driver: a two-PWM driver (AT8236, BTS7960, DRV8411A, BDC-30P, TB67H450, RZ7889, AT8833, DRV8833, MX1508) needs two pins per motor instead of three, plus an optional enable it holds high. driver_type picks the firmware's drive scheme, not the chip: every name in that list selects the same two-PWM scheme. The comparison is in Pin Matrix & Wiring.
• IMU: a 9-axis IMU with a magnetometer (ICM-20948) holds its heading; a 6-axis one drifts in yaw. See Sensors & Maps.
• Where the LiDAR goes: on the robot computer's USB keeps the micro-ROS link for the base (Pico 2 Mecanum, XRP). On the MCU, it saves a cable and a port: sent as raw_scan over micro-ROS (UNO Q) or over Wi-Fi (Maker's Pet). The Waveshare board can do either.

---

Back to Home · Pin Matrix & Wiring · Building a Real Robot