I Gave My Robot a LiDAR With One Prompt. Now It Can See

A robot that drives is fine. A robot that can sense the world around it is where things get interesting.

A robot that can't sense its environment is really just a machine that moves. Getting that first sensor online, properly online, is where a lot of robotics projects stall. This post picks up the mobile robot simulation from the last build and adds a LiDAR sensor to it in ROS 2 and Gazebo, turning a robot that drives into one that can actually perceive what's around it.

The problem: a robot that drives but senses nothing

From the last build we have a working mobile robot simulation. It drives, and Gazebo is running. But there's no sensor data coming out of it. No /scan topic, nothing for a mapping or navigation algorithm to consume.

That gap matters more than it looks. Sensing is the first step of the sense, think, act loop that nearly every robot runs on. Without it, the "think" and "act" steps have nothing real to work with. So the next move is clear: give the robot a LiDAR.

How to add a LiDAR sensor to the robot in one prompt

Wiring a LiDAR into an existing robot usually means hand-editing the URDF to add a sensor link and joint, dropping in a Gazebo sensor plugin, and making sure the frame names and topic remappings all line up. Miss one and the sim launches but publishes nothing. If you want the full manual version, the Nav2 sensor setup guide walks through it step by step.

Instead of doing that by hand, I asked Drift to integrate the sensor into the existing workspace:

"Integrate a LiDAR sensor into the existing robot simulation."

Here's what it did, in order:

• It read the existing setup first: Drift went through the current URDF and package structure before changing anything, so the additions matched the robot already defined.
• It added the LiDAR link, joint, and Gazebo ray sensor plugin: That's the trio you need: a link representing the sensor, a joint attaching it to the robot, and the ray sensor plugin that makes Gazebo actually produce scan data.
• The frame names and topic stayed consistent: The new sensor frame matched the rest of the transform tree, and the scan topic was mapped correctly. That alignment is exactly where hand-wiring usually breaks, and getting it wrong is why a sim can run while RViz shows nothing.

Why this is the moment robotics gets real

Robotics starts to feel real the moment a robot senses the world around it. Movement alone never quite gets there. Once the LiDAR is publishing, the robot stops being a thing that drives in the dark and becomes something that can react to what's actually in front of it.

And once sensor data is flowing, the rest of the stack opens up. Mapping. Navigation. Autonomy. All of it depends on a clean stream of sensor data and a transform tree that lines up, which is the part we just put in place. Instead of fighting URDFs, frame names, and plugins for an hour, the integration happened in context, against the workspace that already existed.

What's next: from sensing to navigation

The robot can finally see. That's the foundation everything else is built on.

The next step is teaching it to use that sensor stream to find its way around, which means moving into mapping and the navigation stack. If you're building your own simulation, this is the point to get your sensor data clean and your frames consistent before you layer navigation on top.

Watch the full integration in the video above, and follow along to the next build where we teach this robot to navigate.

FAQ

• Why does my robot simulation have no /scan topic or sensor data?
• Usually because the robot has a body and can move, but no sensor has been added to the URDF, or the sensor plugin and topic remapping aren't configured. A robot that drives in Gazebo will still publish nothing until a LiDAR or other sensor is wired in with a matching frame and topic.
• How do you add a LiDAR sensor to a robot in ROS 2 and Gazebo?
• With Drift, you describe it in a single prompt and it edits your existing workspace in context: adding the LiDAR link and joint to the URDF, attaching the Gazebo ray sensor plugin, and mapping the output to a topic such as /scan with a consistent frame name. Those are the same edits you would otherwise make by hand before rebuilding and checking the scan data in RViz, which is where mismatched frames or topics usually trip people up.
• What is the Gazebo ray sensor plugin?
• It's the Gazebo plugin that simulates a laser range sensor by casting rays in the simulated world and publishing the results as a LaserScan message, the same message type a real LiDAR would produce. It's what turns a static sensor link into a working data source.
• Can Drift add a sensor to an existing URDF or use custom plugins?
• Yes. Drift accepts existing URDF and SDF files and extends them in place, and it configures standard Gazebo plugins like LiDAR, cameras, IMUs, and depth sensors automatically. For custom or third-party plugins, you name them in the prompt and Drift adds the plugin block, though you may still need to verify build paths and parameters.
• What is Drift?
• Drift is an end-to-end robotics simulation engineering agent. It turns natural-language prompts into simulation workspaces for ROS2, Gazebo, MuJoCo, and Isaac Sim, generating URDF, SDF, and world files, configuring plugins and controllers, and scaffolding colcon workspaces.