At Zarego, we have been working with robotics technologies, combining our software engineering experience with platforms such as ROS 2 to develop applications that connect software with the physical world.
In a recent project for a client, we built a small experimental rover called ESPi70. Our goal was to validate whether a compact robot could move around a room, detect obstacles, and explore its surroundings. This was the first step for this project: Build a proper Hardware SDK for the project.
Since a ready-made robotic platform was beyond the project’s budget, we built our own prototype using off-the-shelf components: two driven wheels, an ESP-32 microcontroller, and an ultrasonic proximity sensor. This gave us an affordable platform for validating the hardware and developing the software that would control its behavior.
From browser-based movement controls to obstacle avoidance with ROS 2, ESPi70 allowed us to validate the first stage of the project and identify what the next version would need.
Why We Chose ROS 2
ROS, short for Robot Operating System, began in 2007. Despite its name, it is better understood as a collection of libraries, tools, and conventions for building robot applications. It helps developers connect components, exchange data, and reuse software across projects.
ROS 2 followed with its first distribution in 2017, addressing requirements such as distributed systems, less reliable networks, and deployment beyond research environments. In 2026, the ecosystem includes mature tools for navigation, visualization, and simulation. Its latest long-term support release, Lyrical Luth, arrived in May 2026, with support scheduled through May 2031.
For us, the appeal is practical. When programming a robot, we want to spend our time developing its behavior. Building every communication mechanism from scratch would leave us less time to work on the decisions that make the robot useful.
ROS 2 organizes software into nodes that exchange messages through defined interfaces. One node can publish sensor readings while another uses them to decide how the robot should move. We still need to configure communication, interpret measurements, and handle failures, but we have an established foundation.
We can also develop application logic in C++ or Python and test it in simulation using tools such as Gazebo. Simulators let us examine behavior before running it on physical hardware, although real-world testing remains essential. That combination fits how we like to work: experiment, observe, and refine.
ESPi70 Starts with the Hardware
Figure 1. The first version of ESPi70.
Our first prototype brought together off-the-shelf components, a compact chassis, and the wiring needed to connect them. The priority was to assemble a working platform that would let us validate the client’s concept before committing to more specialized hardware.
Before introducing ROS 2, we wrote a C program for the ESP-32 that let us control ESPi70 through a web interface. We used it to verify that the microcontroller communicated with the motor driver, the wheels responded as expected, and the sensor returned usable readings.
The ESP-32 hosted the interface through its own web server. We checked the router to find the IP address assigned to the board, opened that address on a phone, and controlled the robot from the browser.
This validation reduced uncertainty before we added more software. Establishing that the motors and sensor worked in a simpler setup gave us a baseline for troubleshooting the ROS 2 integration.
Our focus was the software that would control the robot’s behavior. Building the hardware prototype gave us a practical way to develop and test that software within the project’s budget.
Video: ESPi70 in action.
Connecting ESPi70 to ROS 2
Figure 2. ESPi70 system architecture, connecting the ESP-32 to ROS 2 through micro-ROS over Wi-Fi.
Once ESPi70 could move and read its proximity sensor, we connected it to ROS 2. The sensor was an ultrasonic module that measured the distance to an object in front of the robot. For our first behavior, we used ten centimeters as the obstacle threshold.
Our development environment ran Ubuntu inside a virtual machine on a Mac. We configured networking so the virtual machine had its own IP address on the local network and could communicate with the ESP-32. Getting that networking configuration right was essential for communication between the robot and ROS 2.
On the robot, we installed C++ firmware using micro-ROS, which connects microcontrollers to the ROS 2 ecosystem. A micro-ROS agent running in the Linux environment provided the connection between the board and the ROS 2 nodes. Sensor readings and movement commands traveled over Wi-Fi using UDP.
The architecture separated responsibilities. The ESP-32 handled the proximity sensor and motor driver, while the ROS 2 application handled the robot’s behavior. Topics carried range measurements, wheel commands, and status information between the components.
We first published proximity readings and verified that they arrived in ROS 2. This confirmed the sensor-to-application communication path before we introduced movement decisions.
A Simple Exploration Algorithm
With communication working, we implemented a basic obstacle avoidance loop:
- Check whether an object is within ten centimeters.
- If an object is detected, turn approximately 90 degrees clockwise, then check again.
- Otherwise, move forward approximately eight centimeters, then repeat.
This validated the complete control loop: a sensor reading reached the application, the application selected an action, and a command returned to the robot. ESPi70 could now respond to obstacles without someone controlling each movement through the browser.
The distances and angles were approximate. Without precise feedback about wheel rotation or orientation, issuing a movement command did not tell us exactly where ESPi70 ended up. The robot could react to an obstacle, but reliable mapping would require better information about its own movement.
That distinction shaped our next step. We wanted ESPi70 to begin building a map of the area it explored, yet we lacked accurate wheel measurements and a gyroscope to help estimate its heading. Those limitations gave us concrete requirements for another hardware iteration.
ESPi80 Brings a Phone Onboard
Figure 3. ESPi80, the next hardware prototype, under construction.
For ESPi80, we are keeping the ESP-32 responsible for low-level movement and adding a smartphone as the planned onboard computer for ROS 2.
A phone brings several capabilities in one device: a gyroscope, GPS, a camera, and a microphone. We want to explore how those resources can support perception and movement estimation. Their usefulness will depend on the task: GPS, for example, will not give us precise indoor positioning, and a gyroscope alone will not solve localization.
We also plan to replace the Wi-Fi connection between the controller and the ROS 2 computer with a cable. Bringing the computer onboard and using a wired link should simplify that communication path. Integrating the phone, accessing its sensors, and running the software remain part of the work ahead.
ESPi70 gave our client a working proof of concept for the first stage of the project. Using off-the-shelf components kept the hardware investment within budget while allowing us to validate movement, sensor communication, and obstacle avoidance. That provided a concrete basis for deciding what to build next.
Building Software for Connected Operations
For companies exploring robotics or connected devices, the first challenge is often deciding what to automate and how it will fit into existing operations. As we discuss in AI Integration Is an Operations Problem, technical capabilities create value when they connect to clear workflows and useful decisions.
At Zarego, we help define practical proofs of concept, design software architectures, and build the applications and integrations around them. Where a project calls for it, that work can include assembling and integrating prototype hardware, as we did with ESPi70. We can also connect device data to business systems and build dashboards that help operators monitor activity and respond to problems.
If your company is evaluating a project involving robotics, sensors, or automation, talk to us at Zarego. We can help translate the operational goal into technical requirements, identify the assumptions that need testing, and define a practical first stage.
ESPi80 is still taking shape. To be continued.
