AutoServe WIP

AutoServe is an autonomous indoor delivery robot designed to carry up to 10 lbs of payload between locations in a multi-floor building such as a hotel. Staff load items at a central base station and specify a destination room; the robot navigates hallways autonomously along a A*-computed path, avoids unexpected obstacles in real time, and handles elevator entry and exit using barometric floor detection.

An ESP32-S3-WROOM-1-N16 handles all onboard sensing, motor control, odometry, and WiFi communication. A companion computer application runs an A* path search on a pre-loaded grid map of the floor plan (1 ft² tiles, walls and fixed obstacles pre-marked) and sends an ordered list of motion vectors to the robot over WiFi. The physical platform is 7×10 inches, with two 6-inch hall-encoder DC drive wheels and two passive caster wheels, built with help from the ECE Machine Shop.

The following block diagram shows the electrical architecture of the AutoServe robot. The ESP32-S3-WROOM-1-N16 microcontroller coordinates motor control, sensor acquisition, and communication with the base computer. Two linear regulators generate 5V and 3.3V rails: the ESP32 and most sensors run from 3.3V, while peripherals like the ultrasonic sonar use 5V. Drive motors are powered by the 12V battery through motor driver circuits controlled via GPIO signals from the ESP32, with hall-effect encoders providing feedback. Additional GPIO lines interface with the ultrasonic sonar, receive interrupt signals from the I²C sensors, and control the startup of the time-of-flight sensors, while PWM outputs drive scanning servos, enabling coordinated sensing and autonomous navigation.

Block Diagram of the AutoServe robot.

To transition from breadboard prototyping to a reliable embedded platform, the AutoServe electronics were consolidated into custom PCBs designed in KiCad. Two board types were created: a main AutoServe controller board that integrates the majority of the robot electronics, and two small breakout boards for the time-of-flight sensors used in the rotational scanning subsystem.

The main AutoServe PCB integrates the ESP32-S3-WROOM-1-N16 microcontroller module, dual LMD18245 motor drivers, power regulation circuitry, and sensor interfaces into a single board. Battery input from the 12.6V Li-ion pack feeds the motion subsystem directly, while onboard regulation generates 5V and 3.3V rails for logic and sensors. The board also routes encoder inputs, I²C sensor buses, and GPIO control signals needed by the motion and sensing subsystems.

Two identical breakout boards were designed for the VL53L3CXV0DH/1 time-of-flight sensors. These compact boards provide power filtering, I²C connectivity, and mechanical mounting points so each sensor can be attached to a servo motor. This configuration allows the robot to sweep a laser rangefinder across its surroundings to detect obstacles and determine open navigation paths.

At the time of writing, the PCBs have been completed and ordered for fabrication. Hardware bring-up, validation of the power system, and integration with the motor drivers and sensor subsystems will occur once the boards arrive.

AutoServe main controller PCB layout.

Time-of-flight sensor breakout board layout.

The robot runs a finite state machine on the ESP32. The base computer runs an A* search on a pre-loaded grid map and sends a linked list of motion vectors over WiFi. The robot processes these sequentially, checking sensors before each move and verifying actual displacement after each move using fused encoder and IMU data.

• Start — initial boot state where the ESP32 configures peripherals and initializes the onboard WiFi module.
• Startup WiFi — recovery state entered if WiFi initialization fails; repeatedly attempts to restart the WiFi driver until the module becomes operational.
• Connect — waits for the base computer to send an agreed-upon test string verifying that the robot can receive commands.
• Listening — the robot notifies the computer it is ready and fills a linked list of movement commands sent from the computer. Commands begin with a motion start signal and end with either a motion done signal or a no-command termination.
• Sense — the position subsystem polls the obstacle sensors to verify that the next motion segment is clear before the robot moves.
• Move — the motion subsystem receives a vector and distance, computes the required wheel motion, and drives the motors through the motor drivers.
• Halt — immediately stops all motors if an obstacle is detected, preserving remaining movement commands using IMU and encoder feedback.
• Verify — the motion and position subsystems fuse encoder and IMU data to determine the robot’s actual displacement and detect motion error.
• Corrective Motion — calculates and inserts corrective movement commands to compensate for accumulated position error.
• Ride — waits at an elevator entrance and enters when the doors open; the barometric sensor tracks vertical movement while inside.
• Exit — generates movement commands to leave the elevator before resuming the remaining planned route.
• Done — notifies the base computer that the movement list has completed and the robot has arrived at the destination.

The computer-side application runs an A* search on a 1 ft² tile graph of the floor plan with walls and fixed obstacles pre-loaded. It sends motion commands, handles rerouting if the robot reports a stuck state, and provides a GUI for staff to input delivery destinations.

• Autonomous map building to replace pre-loaded static floor plans.
• Extended battery life and increased payload capacity for real deployment scenarios.