Getting Started With Open Source Robot Stacks
I used to think writing custom firmware from scratch was the only way to build something reliable. That changed when I started working on a mobile manipulator project with a team that didn't have time for months of kernel hacking. We switched to open source tooling and it worked out fine, once we stopped expecting it to be magic. ROS 2 is the main framework people use here. It replaced ROS 1 because the middleware situation under ROS 1 was genuinely broken for anything involving real-time behavior or multiple machines talking cleanly to each other. ROS 2 uses DDS as its transport layer, and DDS is actually a standard, which means you can swap implementations if you run into licensing headaches. Fast DDS is the default in most installs. Cyclone DDS tends to be more stable in production scenarios where network performance matters.
Embedded Systems And Robotics With Open Source Tools
The embedded side is where people usually hit walls. ROS 2 is heavy. Running it on a Raspberry Pi 4 is possible but you are going to struggle with CPU load during any non-trivial navigation task. I had a navigation stack eating 140 percent of one core while moving a robot two meters forward at walk speed, which is absurd. The fix was switching from Nav2's default controller to a simpler DWA implementation and reducing the sensor update rate from 30 Hz to 10 Hz. Accuracy dropped slightly but the CPU usage fell to about 40 percent total. That tradeoff is something you figure out after burning a day debugging thermal throttling. For the actual embedded hardware part, you are generally looking at either an NVIDIA Jetson module if you need GPU acceleration for perception, or a standard SBC like the Raspberry Pi or Orange Pi paired with a microcontroller for motor control. The microcontroller runs FreeRTOS or similar real-time firmware and talks to the main computer over serial using something like rosserial or your own custom protocol. Building your own protocol over serial is honestly better in most cases. rosserial has a reputation for dropping messages under load and the message serialization overhead is not trivial. Micro-ROS is the option most people should consider instead. It lets you run a full ROS 2 client library directly on an STM32 or ESP32, so you get topics and services without the rosserial translation layer. The learning curve is steeper because you are working closer to the metal, but the reliability is noticeably better and latency drops to single-digit milliseconds on decent hardware. I switched a wheel encoder node from rosserial to Micro-ROS and saw jitter go from roughly 12 milliseconds to about 1.5 milliseconds consistently. That kind of improvement matters when your PID loop is tuned for responsiveness.
Build systems are another area where beginners waste weeks. Colcon is the default build tool for ROS 2 and it works fine for most projects. If your workspace has fewer than twenty packages it compiles quickly. Once you add more, the build times grow linearly and you will want to look at ccach or just accept slower iterations. There is no real shortcut around this except keeping your workspace lean and using colcon's parallel build options. One thing nobody warns you about is the dependency hell between ROS distributions and Ubuntu versions. Humble Hawksbill runs on Ubuntu 22.04. Iron Irwini runs on Ubuntu 22.04 as well. Jazzy Jalisco runs on Ubuntu 24.04. If you install the wrong package mix you will get unresolved symbols or broken libraries, and fixing it usually means wiping the system and starting fresh rather than trying to untangle the mess. Just pick one distribution and stick with it across all your machines. This is not optional advice. For simulation before you touch real hardware, Gazebo is still the standard despite its reputation issues. The classic Gazebo has been problematic for years. Ignition Gazebo was supposed to fix that but the project got folded back into the main Gazebo effort under the "Gazebo Sim" name. It is better now but not polished. If you are just testing kinematics and basic sensor models, it is adequate. If you need photorealistic rendering or complex physics, look at Isaac Sim from NVIDIA instead, though that requires an NVIDIA GPU and comes with its own licensing complexity.
Get the Full Details
Another tool worth mentioning is Nav2 for autonomy. It handles path planning, localization, and obstacle avoidance in a modular way. The problem is that tuning it takes significant time and the documentation assumes you already understand what most of the parameters do. I spent about three days getting a robot to stop reliably in front of a wall without oscillating. The parameter that controls how aggressively the local planner reacts to dynamic obstacles is buried in the DWBController configuration and there is almost no explanation for it in the docs. Once I found it, I adjusted the inescapable_cost_threshold value and the behavior improved immediately. SLAM is simpler than people make it. Cartographer is powerful but complex. For most embedded projects with a LiDAR sensor, slam_toolbox is plenty good and easier to configure. It runs in both offline and online modes. You can collect data first, tune parameters, then replay it without the robot needing to be present. That debugging workflow saves considerable time compared to always running live on the hardware. There are genuine limitations to this whole approach. Open source robotics tooling is not beginner-friendly out of the box. It demands that you understand Linux at a reasonably deep level, including package management, permissions, and networking. A lot of the tooling also expects a specific directory layout and environment setup that breaks silently if you deviate even slightly. The community support is real but fragmented across forums, GitHub issues, and Discord servers, and finding a answer to a specific problem can take hours of searching through outdated blog posts.
For teams that need something more deterministic and less fragile, a bare-metal approach with a proper RTOS paired with a lightweight communication layer like ZeroMQ might be more appropriate. It gives you predictability that ROS 2 cannot match in safety-critical applications. But if your project involves autonomy, mapping, or complex sensor fusion, the open source ecosystem currently has no real competitor in terms of features and available code. The best approach is probably to install ROS 2 Humble on a clean Ubuntu 22.04 VM first and work through the basic tutorials before touching any hardware. It is easy to break an installation and harder to troubleshoot when you are also dealing with device drivers and firmware flashing. Building confidence in the software stack separately from the hardware problems makes debugging much less painful.
