A Real Lidar, Not Ultrasonic Sensors

SLAM needs a 360 degree scan published on /scan as a proper LaserScan message. A ring of ultrasonic sensors cannot do that, no matter what the listing claims. Look for a named lidar model, a TOF or triangulation unit such as the D500, MS200 or COIN-D6, and check its stated range and scan rate. A cheap 8 metre triangulation lidar is fine indoors; it will wash out in sunlight, which matters if you intend to drive outside.

Closed Loop Encoder Motors

Odometry is what makes Nav2 usable, and odometry comes from encoders. Open loop hobby motors give you no /odom worth publishing, so localisation has to lean entirely on the lidar and it falls apart the moment the robot is kidnapped or the room is featureless. Insist on encoder motors with a closed loop controller, and if the platform also ships an IMU you can fuse the two with robot_localization and get a genuinely stable pose.

Where the Compute Actually Lives

Three architectures exist here and they are not equivalent. A Raspberry Pi 5 on board runs the whole ROS 2 graph locally and is the normal choice. Pi plus an ESP32 sub-controller splits perception from the motor loop, which is how serious robots are built and worth learning. micro-ROS on an ESP32 with ROS 2 on your laptop is much cheaper but makes the robot dependent on a Wi-Fi link. A Jetson Orin only earns its cost if you are running deep learning on board.

Which ROS 2 Distro Is Pinned

Almost every platform in this category is built and tested against ROS 2 Humble on Ubuntu 22.04, usually shipped as a prepared SD image or a Docker container. That is fine, and Humble is supported until 2027, but understand what it means: moving to Jazzy or a newer Ubuntu is a porting job you own. Before buying, open the vendor’s GitHub repository, check the last commit date, and see whether the drivers are readable ROS 2 packages or an opaque binary blob.

Power Headroom and Run Time

A Pi 5, a spinning lidar, a depth camera and four encoder motors together are a real load, and a Pi 5 alone wants up to 5 V at 5 A under peak. Check that the platform gives the computer a regulated rail separate from the motor supply, because brownouts during a Nav2 run look exactly like a software bug and waste days. Also check whether 18650 cells are included, since several kits ship the UPS module but not the cells.

The MentorPi A1 is the M1’s sibling with the one change that matters if your interest is self driving cars rather than warehouse robots: an Ackermann chassis with servo steering. That single difference rewrites the problem. A car cannot rotate in place, so your planner needs a kinematically feasible path, which is where Nav2’s Smac Hybrid-A* planner and a proper motion model stop being optional reading. It is the closest thing on Amazon to a shrunken F1TENTH style research car with the sensors already fitted. Perception matches the M1: a COIN-D6 lidar, a Nuwa-HP60C depth camera good from 0.2 to 4 metres with sub 2 mm accuracy at a metre, a 170 degree monocular camera, and closed loop Hall encoder motors. Hiwonder’s autonomous driving material is the real draw here, with YOLOv11 training for road signs and traffic lights and a sandbox track you can buy separately. The catch is cost: the variant that includes the Raspberry Pi 5 is meaningfully more expensive than the M1, and steering servo slop on a small Ackermann car will limit how precisely it tracks a path.

The UGV Beast is the UGV Rover’s stack on a chassis that will actually leave the building. It runs tracks on stainless steel independent suspension, 40 mm wide, with a zero turning radius and a deliberately slow default top speed of 0.35 m/s, which is what you want when the terrain is gravel, grass or a doorway threshold rather than a laboratory floor. Everything else carries over: the same Raspberry Pi plus ESP32 dual controller split, the same D500 360 degree lidar and OAK-D Lite depth camera, the same 5 MP 160 degree wide angle module on a 30 kg·cm 2-axis pan-tilt, ROS 2 Humble LTS on Debian Bookworm, a wireless gamepad, a cooling fan and a prepared TF card. It is also the most expandable frame here, with 1020 European aluminium profile rails, boat nuts and M4 hardware supplied specifically so you can bolt on your own sensors. Two honest caveats: this Amazon listing bundles a Raspberry Pi 4B rather than a Pi 5, which is a real compute difference if you plan to run vision on board, and tracked skid steer produces the worst wheel odometry of any drive type in this guide, so plan on fusing an IMU.

Yahboom’s MicroROS-Pi5 car is the friendliest complete ROS 2 platform in this guide, and the one we would pick for a student who has never opened a terminal on a robot. It uses the same architecture as the Waveshare rovers, a Raspberry Pi 5 for the ROS 2 graph and an ESP32 based expansion board with a 6-axis IMU for the motion loop, but wraps it in far gentler documentation and a large set of worked Python 3 examples. The hardware is honest: an anodised aluminium alloy frame, four 310 encoder motors rated around 450 RPM, an MS200 lidar, a 2 MP camera on a 2-DOF gimbal, a 7.4 V 2000 mAh pack and, importantly, a 5.1 V 5 A supply so the Pi 5 does not brown out with the motors running. Software covers SLAM mapping and navigation, RViz simulation and multi machine synchronisation, plus OpenCV and MediaPipe demos for gesture and pose work. Two things to watch. The Amazon variant that includes a Raspberry Pi 5 costs a lot more than the bare chassis, and the sibling listing without the Pi currently sits at 3.8 stars from a handful of buyers, with the usual complaints about translated documentation.

The ROSMASTER M3 Pro is the only platform here that is a mobile manipulator rather than a mobile base, and it is priced accordingly. This one sits far above any reasonable hobby budget, several times the cost of the MentorPi M1, so buy it only if a department, a lab or a funded project is paying. What that money gets you is genuinely research grade for the class: two TOF lidars mounted diagonally so the robot keeps full 360 degree coverage even with the arm folded over the chassis, a binocular structured light depth camera for 3D grasping, an aluminium chassis with rear pendulum suspension under 80 mm mecanum wheels, and a 6-DOF arm you drive through MoveIt. Because the base publishes proper odometry and the arm has its own kinematic chain, this is a real platform for the mobile manipulation pipeline: navigate to a pose, detect an object in the point cloud, plan a grasp, execute. It runs ROS 2 Humble and the controller is your choice, a Raspberry Pi 5 8GB or 16GB on this listing or a Jetson Orin Nano or Orin NX Super if you need on board deep learning. The multimodal large language model layer is heavily marketed; treat it as a demo, not the reason to buy.

This is the cheapest honest route into ROS 2 on real hardware, and it works by moving the expensive part off the robot. There is no Raspberry Pi and no Jetson on board. Instead an ESP32 runs micro-ROS, publishes over Wi-Fi UDP to a micro-ROS agent, and the full ROS 2 Humble graph, SLAM, Nav2 and RViz all run in a virtual machine on your laptop. For a microcontroller engineer that is a genuinely instructive architecture, because it forces you to see where the DDS boundary sits and what a micro-ROS node actually is, and it is the same pattern used on real embedded robots where the MCU owns the motors. The chassis is not a toy either: aluminium alloy, four 310 encoder motors, a TOF lidar, a 7.4 V pack, gamepad and app control, and mapping plus RViz and multi machine sync in the supplied examples. It also carries the highest review score in this guide, though from only a handful of buyers. The trade offs are real: your laptop must stay on the same Wi-Fi network, latency and dropouts become part of your control loop, the standard edition ships without a camera, and Yahboom’s virtual machine image is Windows and Linux only, with no macOS support.

Want one platform that just works?

The Hiwonder MentorPi M1 arrives with a TOF lidar, a 3D depth camera, encoder motors and a working ROS 2 Humble Nav2 configuration, which is everything the stack needs and nothing you have to source yourself.

Want to read and rewrite the stack?

The Waveshare UGV Rover publishes its whole software stack openly with a detailed wiki, and its Pi plus ESP32 split is the architecture you will meet again on real industrial robots.

Working on self driving cars?

The Hiwonder MentorPi A1 uses Ackermann steering, so your planner has to respect car kinematics, and its YOLOv11 road sign and traffic light pipeline is already set up.

Does it have to go outside?

The Waveshare UGV Beast runs tracks on stainless steel independent suspension and will cross grass, gravel and thresholds that stop every wheeled platform in this guide.

Brand new to ROS 2 entirely?

The Yahboom MicroROS Pi5 car gives you a full Pi 5 ROS 2 stack with the gentlest documentation and the largest set of readable Python examples of anything here.

Need the robot to pick things up?

The Yahboom ROSMASTER M3 Pro is the only mobile manipulator here, with a 6-DOF MoveIt arm, dual lidar and a structured light depth camera. Budget accordingly.

Smallest possible budget?

The Yahboom MicroROS ESP32 kit puts micro-ROS on the robot and ROS 2 on your laptop, which cuts the cost roughly in half and teaches you where the DDS boundary really is.

Buying for a course or a lab?

Check whether your syllabus is written against the TurtleBot 4 before you buy anything else, since course material assumes its exact topic and frame names. Otherwise standardise a class set on one MentorPi or UGV variant so every student debugs the same stack.

What actually makes a robot “ROS 2 compatible”?

Far less than most listings imply. A robot is usefully ROS 2 compatible when it ships driver nodes that publish the standard topics: a sensor_msgs/LaserScan on /scan, a nav_msgs/Odometry on /odom, a correct TF tree linking odom → base_link → laser, and a geometry_msgs/Twist subscriber on /cmd_vel. If those four exist and are honest, SLAM Toolbox and Nav2 will work. Many cheap “ROS robots” ship only a Python SDK and a marketing claim, so check the vendor’s GitHub for actual ROS 2 packages before you buy.

Raspberry Pi 5 or Jetson Orin for a ROS 2 robot?

A Raspberry Pi 5 comfortably runs the ROS 2 graph, a lidar driver, SLAM Toolbox and Nav2, plus modest OpenCV work, and it is the right default for almost everyone. A Jetson Orin earns its very large price premium only when you are running deep learning inference on board, for example real time object detection at a useful frame rate, visual SLAM on a depth camera stream, or a local vision language model. If your perception is a 2D lidar and a bit of OpenCV, the Jetson is money spent on nothing. Also budget power: a Pi 5 can want up to 5 V at 5 A, and a Jetson wants considerably more.

Do I need a depth camera, or is a lidar enough?

For 2D mapping and navigation, a lidar alone is enough, and it is the sensor Nav2 is built around. A depth camera earns its place when you need things a single scan plane cannot see: obstacles below or above the lidar plane such as a low table edge or an overhanging shelf, 3D obstacle layers in the costmap, object pose estimation for grasping, or visual SLAM. If your budget forces a choice, buy the lidar first. If you plan to do manipulation or you want the robot to notice a step, the depth camera stops being optional.

Why is everything still on ROS 2 Humble instead of Jazzy?

Because vendors pin an entire tested stack, not just a distro name. Humble targets Ubuntu 22.04, has a long support window, and by now every driver, tutorial and forum answer in this category assumes it. Newer distros mean a newer Ubuntu, rebuilt vendor drivers and re-validated demos, which is work that only happens when the old release nears end of life. Practically, this means two things when you buy: use the vendor’s supplied image or container rather than fighting it, and if you specifically need a newer distro, budget time to port the lidar, camera and base controller drivers yourself.

Can I build my own ROS 2 robot instead of buying a kit?

You can, and you will learn a lot, but be clear about what you are signing up for. Building means sourcing a chassis with encoder motors, a motor driver, a lidar with a working ROS 2 driver, an IMU, a power system that will not brown out the Pi, and then writing the base controller node, the URDF, the TF publishers and the ros2_control hardware interface yourself. That is a rewarding month or two of work and an excellent portfolio piece. A kit costs more in cash and less in time, and it lets you start on the interesting part, SLAM and navigation, on day two. A reasonable middle path is buying a cheap kit like the MicroROS ESP32 chassis and replacing its software with your own nodes.