If you’ve walked through a college campus, waited for a late-night restaurant drop-off in a downtown neighborhood, or even grabbed a package from a grocery run delivered to your office lobby, chances are you’ve crossed paths with one of our multi-scenario delivery robots. When I started this business seven years ago, my team and I built our first prototype in a garage, guessing at sensors instead of testing them for real-world use. We thought more cameras would solve every problem—until that robot crashed into a fire hydrant on its very first delivery run. That mistake taught me something critical: a multi-scenario delivery robot isn’t just a box on wheels. It’s a mobile system that needs to “see” its surroundings, “feel” its limits, and “understand” its space across sidewalks, office hallways, campus quads, and even indoor warehouses. Today, I’m breaking down the exact sensors we rely on for every delivery robot we build, based on years of fixing those early flaws and refining each component to work no matter where our robots go. Multi-scenario Delivery Robot
Let’s start with the foundation of any good delivery robot: perception. These robots need to map their environment in real time, whether they’re navigating a crowded sidewalk with students weaving between benches or an empty office hallway after hours. That’s where LiDAR comes in, and I’m not talking about the cheap, low-range ones you might find on a toy robot. We use 360-degree mechanical LiDAR sensors, mounted at the top of each robot, that spin 10 times per second to send out millions of laser beams every minute. Each beam bounces off walls, fire hydrants, people, bikes, and other obstacles, creating a precise 3D point cloud map. Last winter, when we ran a pilot at a university in Minnesota, this sensor was the only one that could reliably detect ice patches on sidewalks—something cameras struggled with because snow and ice looked almost identical to wet concrete in low light. The LiDAR doesn’t just stop at detecting obstacles; it also lets our robots localize themselves. Our algorithms compare the real-time point cloud to a preloaded map of the delivery area, so the robot never gets lost, even when GPS cuts out (which happens all the time in dense urban areas or under tall campus buildings). We don’t cut corners here—cheaper LiDARs would miss small obstacles like a toddler’s stroller or a loose curb, and we learned the hard way that missing even one small obstacle leads to a damaged robot, a lost delivery, and a frustrated customer.
Next up, we have cameras, but not just any cameras. Cameras are for context, and they fill in the gaps that LiDAR can’t. We pair our main LiDAR with a set of stereo vision cameras, mounted at chest level on the robot, that see in high resolution and capture color data. LiDAR tells us there’s an object in front of us, but cameras tell us what that object is. For example, if a LiDAR picks up a small, low obstacle, the camera can identify it as a parking cone (something we can safely go around) versus a loose fire extinguisher (something we need to stop for). In indoor settings, cameras help our robots read signs: a “no entry” sign that blocks a hallway, a door that’s propped open for deliveries, or a specific drop-off zone marked on an office floor. We also use our front-facing camera to interact with people—if a pedestrian steps into the robot’s path, the camera can recognize a human gait, their distance, and whether they’re moving toward or away from the robot, which lets us adjust speed smoothly instead of slamming on brakes (something we got complaints about early on, when our robot stopped suddenly for a mailroom cart that LiDAR detected but cameras couldn’t identify). We also add a fisheye camera to the back of each robot, which is critical for reversing in tight spaces like narrow alleyways or crowded sidewalks, giving us a 180-degree view of everything behind us.
But LiDAR and cameras can’t handle everything. What if it’s pitch black outside, like a late-night delivery to a downtown bar district, or the robot is in a dimly lit office basement where cameras can’t pick up details? That’s where ultrasonic sensors come in, often called sonar sensors, mounted on the lower sides and front of the robot. These high-frequency sound waves bounce off nearby objects, measuring distance in centimeters, and work perfectly in low light or complete darkness. They’re especially good at detecting soft, absorbent obstacles that LiDAR might miss, like a backpack or a person’s coat. When our robot is pulling up to a door to make a delivery, ultrasonic sensors let it stop at exactly the right distance, not too close that it bumps the handle, not too far that someone has to reach across a gap to grab their package. We test these sensors in heavy rain and snow too—something that’s non-negotiable for a delivery robot, since we need our robots to work no matter the weather. Early prototypes had ultrasonic sensors that would get clogged with slush in winter, so we redesigned their housings to be heated, which is a small detail that makes a huge difference in regions with harsh winters.
GPS is another key sensor, though we treat it as a complementary tool, not a primary one. Our robots use RTK (Real-Time Kinematic) GPS, which is way more accurate than standard consumer GPS. Instead of being off by a few meters, RTK GPS gives us position data accurate to within 2 centimeters, which is enough to guide the robot to the exact curb or building entrance it needs to reach. But as I mentioned before, GPS dies in places like parking garages or dense urban canyons where tall buildings block satellite signals. That’s why we pair RTK GPS with our LiDAR localization and wheel odometry—wheel odometry uses the rotation speed of the robot’s wheels to calculate distance traveled, though we have to correct for wheel slippage when it’s icy or the robot is on loose gravel. Together, these three systems make sure the robot never loses its way, even when GPS cuts out for hours at a time. We learned this during a pilot in Chicago, where one of our robots got stuck between two tall office buildings for 45 minutes because GPS failed, but LiDAR and wheel odometry kept it moving toward its destination safely.
Now, let’s talk about the sensors that keep the robot safe when it’s interacting with people and making deliveries. When a robot pulls up to a curb or a door, it needs to know when someone is approaching to take the package, and it needs to stop if a kid or a pet gets too close. That’s where our time-of-flight (ToF) sensors come in, mounted low on the front of the robot. These sensors are short-range, so they only detect objects within a few feet, and they can pick up movement extremely fast. If a toddler runs in front of the robot at full speed, the ToF sensors register that movement in milliseconds, and the robot stops immediately—something LiDAR is good for long-range detection but a little slower to react to. We also have tactile sensors on the robot’s outer shell, which are soft and padded, not hard plastic. If the robot bumps into something accidentally, like a parked bike or a person’s bag, the tactile sensors send a signal instantly to stop all movement. This is a last line of defense, but it’s been a game-changer for reducing damage claims. Early prototypes had hard shells that would scratch bikes or hurt people if they bumped, so switching to flexible, pressure-sensitive tactile sensors made our robots feel safe to be around, even in crowded spaces.
We also can’t forget about environmental sensors, because a delivery robot needs to adapt to weather and terrain to work across multi-scenario settings. Temperature sensors monitor the inside of the robot’s compartment to make sure perishable deliveries (like groceries or medicine) stay within the correct temperature range—something we tested rigorously during a pilot with a local pharmacy, where we delivered cold insulin and vaccines. Humidity sensors also help, for when we’re delivering packages to areas like a basement storage unit or a outdoor dock during a rainstorm. We even have ground clearance sensors that measure how high the robot is off the ground, to make sure it doesn’t get stuck on curbs or uneven sidewalks. If the ground clearance is too low, the robot will slow down or find a different route, which prevents us from having to tow a stuck robot back to the hub.
A lot of people ask me why we don’t just use cheaper sensors to keep costs down. The answer is simple: consistency across scenarios. A delivery robot that works perfectly on a college campus might crash in a downtown area because the sidewalks are uneven, or fail in a warehouse because it can’t detect pallets. Every sensor we choose is tested across all our use cases, from campus quads to hospital hallways to urban sidewalks. We recently upgraded our LiDAR system after a customer in Boston told us their robot missed a parked scooter on a narrow sidewalk, which caused a minor collision. We worked with our sensor partners to adjust the point cloud resolution to pick up smaller objects in tight spaces, and that small update reduced similar incidents by 80% in our next pilot.
At the end of the day, our delivery robots are built to solve a real problem: making deliveries reliable, efficient, and safe, no matter where they need to go. The sensors aren’t just parts on a robot—they’re the reason our robots can work from 9 a.m. to midnight, handle rain, snow, and crowded crowds, and get a hot pizza or a prescription to someone on time. If you’re looking for a delivery solution that works across multiple scenarios, and you want to learn more about how our sensor setup can be tailored to your specific space, we’d love to chat. Whether you’re a university looking to streamline campus deliveries, a restaurant wanting to cut wait times, or a logistics company expanding your last-mile network, our team can walk you through how our robots operate, how our sensors adapt to your unique environment, and what that means for your delivery reliability. Reach out to our team to start a conversation, and we can build a custom delivery solution that fits your needs.
Customized AMR/AGV Robot References
Thrun, S. (2006). Probabilistic Robotics. MIT Press.
Borenstein, J., Everett, H. R., & Feng, L. (1996). Navigating Mobile Robots: Sensors and Techniques. A K Peters/CRC Press.
Kaiser, J., & Biber, P. (2015). 3D LiDAR-based mapping and localization for autonomous mobile robots. Robotics and Autonomous Systems, 73, 112-123.
Chen, L., et al. (2020). Stereo vision and LiDAR fusion for pedestrian detection in autonomous delivery robots. IEEE Transactions on Intelligent Transportation Systems, 22(8), 4812-4823.
Shenzhen Ezhan Technology Co., Ltd.
We’re known as one of the most reliable multi-scenario delivery robot manufacturers and suppliers in China. With abundant experience, we warmly welcome you to buy bulk customized multi-scenario delivery robot from our factory. If you have any enquiry about cooperation, please feel free to email us.
Address: Room 1808, 1809, 1810, Building 2, Aipark, Baolong 4th Road, Longgang District, Shenzhen City
E-mail: sales01@ezhankeji.com
WebSite: https://www.ezhanrobot.com/
