Programming a delivery robot for indoor navigation requires integrating hardware with software to enable precise movement through enclosed spaces such as warehouses, hospitals, offices, and manufacturing floors. As the demand for automation grows, understanding how to build and program such a system becomes valuable for engineers, hobbyists, and robotics teams. Indoor navigation poses unique challenges when compared to outdoor GPS-based systems, because signals are often unavailable or unreliable inside. Instead, robots must rely on a combination of sensors, localization algorithms, and path-planning logic to move safely and efficiently between points.

This guide provides an authoritative, production‑ready approach to programming a delivery robot for indoor environments. It covers the core hardware components, the software stack, the algorithms that drive navigation, and practical steps to develop a reliable autonomous system. Whether you are building a prototype for a university lab or deploying a fleet for commercial use, the principles discussed here will help you create a robust indoor navigation solution.

Understanding the Basics of Indoor Navigation

Indoor navigation requires the robot to perceive its environment, localize itself within that environment, plan a path to a goal, and execute motion while avoiding obstacles. Unlike outdoor systems that rely on satellite signals, indoor navigation often uses sensing technologies such as Lidar, ultrasonic rangefinders, depth cameras, and infrared sensors. The robot must build or use an existing map of the space and continuously update its position relative to that map.

Two fundamental tasks form the core of any indoor navigation system:

  • Localization – estimating the robot’s position and orientation within a known or unknown environment.
  • Mapping – constructing a representation of the environment that the robot can use for planning and re‑planning.

When both tasks are performed simultaneously, the process is known as Simultaneous Localization and Mapping (SLAM). Many modern delivery robots implement SLAM to adapt to changing indoor spaces, such as moving shelves or temporary obstacles.

Key Components for Programming a Delivery Robot

Before writing a single line of code, you must select the hardware that provides the necessary computing power, sensing, and actuation. The following components are typical for an indoor delivery robot:

  • Microcontroller or Single‑board Computer: A Raspberry Pi, NVIDIA Jetson, or Arduino board acts as the brain. The choice depends on processing requirements: uncomplicated line‑following may need only a microcontroller, while full SLAM and path planning benefit from a more powerful SBC like a Jetson Nano or a Raspberry Pi 5.
  • Sensors: Lidar (e.g., RPLIDAR, SICK) provides 360‑degree range data; ultrasonic sensors detect close obstacles; depth cameras (Intel RealSense, Microsoft Kinect) give RGB‑D information; and infrared sensors help with floor detection or docking.
  • Motors and Motor Drivers: DC motors with encoders, servos for steering, or stepper motors for precision. Motor drivers such as L298N or DRV8825 translate the control signals into motion.
  • Power Supply: Lithium‑polymer or Li‑Ion batteries with sufficient capacity for extended runs. A regulated power supply is critical to avoid brownouts during peak sensor and motor loads.
  • Navigation Software: Algorithms for path planning (A*, Dijkstra), obstacle avoidance (Dynamic Window Approach, Vector Field Histogram), and localization (particle filters, SLAM).

The combination of these components must be chosen to match the operating environment. For a flat, obstacle‑scarce office corridor, a basic ultrasonic sensor and a reactive avoidance algorithm may suffice. For a cluttered warehouse, a Lidar‑based SLAM system is strongly recommended.

Selecting Sensors for Your Use Case

Sensor selection directly affects navigation performance. Lidar is the gold standard for indoor mapping because it provides high‑resolution distance measurements regardless of lighting. Ultrasonic sensors are inexpensive but can suffer from interference and poor angular resolution. Cameras offer rich semantic information but require significant computational power and good lighting. Many professionals combine Lidar with an inertial measurement unit (IMU) and wheel odometry to improve localization reliability.

Software Stack and Algorithms

Most indoor navigation systems for delivery robots are built on top of the Robot Operating System (ROS) 2, which provides a flexible framework for sensor drivers, state estimation, and control. The software stack typically includes:

  • A sensor driver layer that publishes raw data.
  • Localization and mapping modules (e.g., slam_toolbox).
  • A global path planner that computes a route from start to goal.
  • A local path planner that refines the route and avoids dynamic obstacles.
  • A motion controller that sends velocity commands to the motors.

Operating System and Middleware

ROS 2 (Robot Operating System) is the de facto standard for research and commercial robotics. It handles inter‑process communication, provides standard data types for sensor messages, and includes many ready‑to‑use navigation packages. For embedded systems with limited resources, a custom lightweight framework may be used, but ROS 2 dramatically accelerates development.

Sensor Data Processing

Raw sensor data must be filtered and fused before it can be used for navigation. For example, Lidar scans are often cleaned of noise using median filters, and wheel encoder ticks are converted to odometry estimates. Sensor fusion combines these inputs using algorithms such as the extended Kalman filter or particle filter to produce a more accurate position estimate.

Path Planning Algorithms

Two main categories of path planning exist:

  • Global path planning finds the optimal route on a static map. Common algorithms include A* (A‑star) and Dijkstra. A* is typically faster due to its heuristic, while Dijkstra guarantees the shortest path. For indoor environments, A* with a grid‑based map works well.
  • Local path planning adapts the global path in real‑time to avoid obstacles detected by sensors. The Dynamic Window Approach (DWA) and Time‑Elastic Band (TEB) planner are popular choices. They compute safe velocity commands every control cycle.

More advanced applications may use sampling‑based planners like Rapidly‑exploring Random Trees (RRT) for non‑holonomic robots or D* Lite for dynamic environments.

Localization and Mapping (SLAM)

SLAM algorithms enable a robot to build a map while simultaneously determining its location within that map. For 2D indoor navigation, Gmapping (a particle‑filter‑based approach) and Cartographer (a graph‑based SLAM from Google) are widely used. These algorithms require a reliable source of odometry (wheel encoders) and periodic sensor data such as Lidar scans. The output is an occupancy grid map that can be saved and reused for future missions.

If the environment changes frequently, the robot must periodically update its map. Some systems run SLAM continuously in a low‑priority background thread, while others use pre‑mapped landmarks (e.g., QR codes or RFID tags) to correct for drift.

Programming Steps for Indoor Navigation

The development process can be broken into discrete phases. Each phase builds upon the previous one, and thorough testing at every stage prevents cascading failures.

1. Set Up Hardware and Integrate Drivers

Connect the sensors, motors, and battery to your computing platform. Install the necessary drivers and ensure that each sensor publishes data to a ROS 2 topic (or equivalent). Verify that motor commands produce the expected movement without stalling or overheating. This is the most mechanical step and often reveals wiring issues or power supply problems.

2. Calibrate Sensors

Calibration ensures that sensor readings correspond to real‑world measurements. For Lidar, you may need to adjust the offset between the sensor frame and the robot base. For wheel odometry, run a calibration routine that measures how many encoder ticks correspond to a meter of travel. Inaccurate calibration will cause drift in localization and poor navigation performance.

3. Implement Sensor Data Processing

Write processing nodes that filter, transform, and fuse sensor data. Common tasks include converting Lidar scan messages into point clouds, applying an IMU bias correction, and computing odometry from encoder ticks. This processing runs at high frequency to provide a clean stream of data to the higher‑level planners.

4. Develop / Configure Navigation Algorithms

Integrate a global path planner and a local planner. Start with the default parameters provided by ROS 2 Navigation2 and then tune them for your robot’s kinematics and environment. Key parameters include maximum velocity, acceleration limits, obstacle inflation radius, and planning frequency. Use simulation tools (e.g., Gazebo) to test the planners without risk of collision.

5. Integrate Motor Control

Wire the output of the local planner (linear and angular velocity commands) to your motor driver. Implement a PID controller to ensure that the robot actually moves at the commanded speeds. Without proper low‑level control, the high‑level planners will fail because the physical response will lag behind the planned trajectory.

6. Test and Refine

Begin testing in a controlled, obstacle‑free environment. Gradually introduce obstacles and delivery points that require the robot to navigate around corners and through doorways. Observe the robot’s behavior and note any instabilities, such as oscillation near obstacles or failure to reach the goal within a time limit. Adjust planner parameters, sensor fusion weights, and PID gains iteratively.

Advanced Techniques and Tips

Once you have a basic system working, several enhancements can improve reliability and efficiency.

  • Sensor Fusion: Combine Lidar, IMU, and wheel odometry to maintain robust localization even when one sensor degrades. The robot_localization package in ROS 2 simplifies this.
  • Fiducial Markers: Place AprilTags or QR codes at key locations (e.g., delivery stations, charging docks). The robot can use camera markers to reset accumulated drift and achieve sub‑centimeter accuracy.
  • Multi‑robot Coordination: For fleets of delivery robots, implement a central dispatch system that avoids collisions by assigning paths through a shared occupancy grid. This is where a fleet management platform like Directus can be integrated to handle databases of delivery tasks and robot status.
  • Safety Systems: Include hardware emergency stops, bumper sensors, and software‑defined safety zones. Your robot should be able to stop within a controlled distance if a person suddenly steps in its path.

Dealing with Dynamic Environments

Indoor spaces change: doors open and close, furniture is moved, and people walk through corridors. Your navigation system must handle these changes gracefully. Use a local planner that replans at high frequency (e.g., 50 Hz), and consider running an occasional global replan if the robot is blocked for too long. For persistent changes, trigger a map update using SLAM in “mapping mode” to incorporate the new layout.

Edge Cases: Elevators and Ramps

If the robot must use elevators, it will need to interact with buttons (often via a robotic arm or a special interface) and detect the elevator’s arrival. Ramps require careful torque control to avoid sliding. These cases often need custom sensor input and state machines beyond standard indoor navigation algorithms.

Real‑World Applications and Considerations

Indoor delivery robots are already deployed in many sectors. Hospitals use them to transport medications and lab samples, reducing staff workload. Warehouses use automated guided vehicles (AGVs) to move inventory between zones. Offices and hotels deploy robots to deliver mail, packages, or room service. Each application imposes different requirements: hospital robots must be silent and have smooth acceleration; warehouse robots need durability and high speed; office robots often require a simple user interface for calling deliveries.

When scaling from a prototype to a production system, consider the cost of sensors, battery life, and maintenance. Lidar sensors from SICK or Hokuyo are robust but expensive; consumer‑grade RPLIDAR units are affordable but may have lower reliability. Most commercial delivery robots now use a combination of Laser and vision‑based SLAM for redundancy.

Conclusion

Programming a delivery robot for indoor navigation is a challenging but rewarding task that requires careful integration of hardware and software. By mastering sensor calibration, path planning algorithms, and localization techniques such as SLAM, you can build a system that moves safely and efficiently in a wide variety of indoor environments. Starting with a solid software framework like ROS 2 and iterating through real‑world tests will accelerate development. As the technology matures, indoor delivery robots will become increasingly capable, making them a valuable asset in automating logistics and reducing human transit burdens.

For further reading, refer to the ROS 2 documentation for a complete navigation stack, the slam_toolbox package for mapping, and a deep dive into A* pathfinding for understanding heuristic search. For those interested in Lidar technology, SICK’s sensor overview provides industrial‑grade insights.