From Box to First Autonomous Run in One Afternoon: A Realistic Onboarding Timeline

TL;DR: For a Leo Rover already equipped and configured with the sensors required for navigation, a first setup—from opening the box to a short autonomous run in a mapped indoor space—can take roughly 4 to 6 hours for someone comfortable with Linux and ROS 2. Battery charging can run in parallel with software preparation, but charging time depends on the battery’s initial state and the supplied charger. The steps that often consume the most time are not assembly or teleoperation, but Wi-Fi configuration in restricted networks, ROS 2 workspace setup on the operator laptop, and tuning Nav2 parameters for the specific environment. This guide breaks the afternoon into concrete hourly blocks with commands you can copy.

Why mobile robot first setup time matters

When a research group or integrator receives a new UGV, the first day sets expectations. If teleoperation works within an hour, the team trusts the platform. If it takes two days to reach a first autonomous drive, momentum stalls and side issues (network policy, missing dependencies, unclear docs) start dominating the schedule. Understanding a realistic mobile robot first setup time helps you plan the day, allocate the right people, and avoid the common trap of scheduling a demo before the robot has ever moved under Nav2.

The timeline below reflects onboarding the Leo Rover in a typical lab or classroom. It assumes ROS 2 Humble on Ubuntu 22.04, a 2.4/5 GHz Wi-Fi access point you control, a flat indoor area of at least 5 by 5 meters, and a compatible navigation sensor configuration, such as a supported 2D LiDAR or depth sensor producing the data required by the selected SLAM and Nav2 setup. Outdoor GNSS runs require additional configuration, testing, and validation in the actual field environment, which is out of scope here.

What the hour-by-hour timeline looks like

The afternoon breaks into six blocks. These are planning estimates rather than vendor-guaranteed measurements; actual time depends on the rover configuration, network and operator experience.

• 0:00 to 0:20 – Unboxing and mechanical check. Remove the rover, antenna, charger, and accessories. Attach any supplied antenna according to the hardware documentation. Verify wheel hubs are tight and that installed sensors and cables are securely seated. Use the tools supplied with the rover where required.
• 0:20 to 3:00 – Battery charging (in parallel). Check the battery state and start charging according to the supplied battery and charger instructions. A full charge may take several hours depending on the battery’s initial state and charger. Use this time for the software steps below.
• 0:20 to 1:00 – First network connection. Power on, connect to the rover’s default Wi-Fi access point, open the configuration UI at the address specified in the current documentation, and either keep AP mode or switch to client mode against your lab network.
• 1:00 to 2:00 – Operator laptop setup. Install ROS 2 Humble, clone the leo_common-ros2 metapackage, build the workspace, and verify topics with ros2 topic list.
• 2:00 to 3:00 – Teleoperation and sensor check. Drive the rover with a gamepad or an available browser-based control interface, confirm the configured camera and navigation sensor topics stream correctly, and record a short rosbag2 for later replay.
• 3:00 to 5:00 – Mapping and first autonomous run. Launch SLAM with a supported sensor configuration, drive a loop to build the map, save it, then launch the Leo-compatible Nav2 configuration and send a goal in RViz2.

Total elapsed time: around 5 hours is a reasonable planning estimate when the network and sensor configuration are ready. Expect longer if you need to negotiate with IT about firewall rules, multicast traffic, or eduroam-style enterprise Wi-Fi.

How the first network connection actually goes

This is where many teams lose their first hour. The Leo Rover can be configured to provide its own Wi-Fi access point. You connect a laptop directly to it, open a browser, and reach the configuration UI. From there you either keep the rover in AP mode (simplest, isolated) or switch it to client mode so it joins your existing infrastructure.

What people underestimate: enterprise Wi-Fi (WPA2-Enterprise, captive portals, MAC filtering) may require configuration that is unavailable in a rover image or web UI, or assistance from campus IT. If your lab network requires certificates, a dedicated router or access point configured for the rover can be faster and more reliable than relying on campus infrastructure.

Once connected, ping the rover at the address configured for your network and check ROS 2 discovery:

ping 10.0.0.1
export ROS_DOMAIN_ID=0
ros2 topic list

The rover address and available topics depend on its network and sensor configuration. Typical topics may include /cmd_vel, camera image topics, IMU data, laser scan data, and odometry. If the topic list is empty, common causes include a domain ID mismatch, incompatible ROS middleware configuration, or a firewall on the laptop blocking DDS discovery traffic.

What the operator laptop setup requires

Ubuntu 22.04 with ROS 2 Humble is a supported reference stack for the Leo Rover software described here. The steps below get you from a clean Ubuntu install to a working workspace in about 45 minutes on a modern laptop with a fast connection.

1. Install ROS 2 Humble desktop following the official ROS 2 documentation.
2. Install colcon and rosdep: sudo apt install python3-colcon-common-extensions python3-rosdep
3. On a fresh system, initialize rosdep if it has not already been initialized:
   sudo rosdep init
rosdep update
4. Create a workspace and clone the Leo packages:
   mkdir -p ~/leo_ws/src && cd ~/leo_ws/src
git clone https://github.com/LeoRover/leo_common-ros2.git
5. Install dependencies: cd ~/leo_ws && rosdep install --from-paths src --ignore-src -r -y
6. Build: colcon build --symlink-install
7. Source: source install/setup.bash (add this to ~/.bashrc to avoid repeating it).

If colcon build fails, check that your Python version matches the ROS 2 Humble target (Python 3.10 on Ubuntu 22.04) and that you have not accidentally mixed ROS 1 and ROS 2 sources in the same shell.

How to run teleoperation and verify sensors

Once topics are visible, teleoperation is the fastest way to confirm the whole stack works end to end. Plug in a gamepad, launch the teleop node appropriate for your configuration, and drive a small figure-eight. Watch the rover’s odometry topic to confirm updates and inspect the camera stream in rqt_image_view to confirm the camera.

Record a bag of the run for later. Replace topic names with those published by your rover:

ros2 bag record /camera/image_raw /imu/data_raw /wheel_odom /cmd_vel

This bag can be useful when you tune Nav2 later. Replaying recorded sensor data offline can be faster than re-driving the rover for every parameter change, although a valid replay workflow depends on recording all topics required by the SLAM or navigation nodes. The education use cases that Fictionlab documents can benefit from this workflow because it lets students iterate without needing lab access.

What mapping and the first autonomous run involve

With teleoperation confirmed, the last two hours cover SLAM and Nav2. Launch slam_toolbox in online asynchronous mode when using a compatible 2D laser scan source, then teleoperate the rover slowly around the room. Use speeds appropriate for the sensor, lighting, floor surface, and available localization data. A 25 square meter room can often be mapped in several minutes, but map quality depends strongly on sensor placement, environmental features, wheel slip, and the SLAM configuration.

Save the map:

mkdir -p ~/maps && ros2 run nav2_map_server map_saver_cli -f ~/maps/lab_map

Then launch Nav2 using the saved map and the Leo-compatible localization, costmap and controller configuration. Open RViz2, set the initial pose with the 2D Pose Estimate tool, and click 2D Goal Pose somewhere reachable. The first autonomous drive is usually short (2 to 3 meters) and may need adjustment. That is normal. Default Nav2 parameters are generic. Tuning the footprint, local costmap inflation radius, obstacle-layer inputs, and controller velocity limits can take additional time, but by that point you may already have a working autonomous stack.

Where teams realistically get stuck

Across first-time ROS 2 mobile-robot deployments, three failure modes account for many delays:

• Restricted Wi-Fi. Enterprise authentication may not be supported by the rover’s current network configuration or may require credentials and certificates from IT. Solution: use a dedicated router or access point, or prepare the required network configuration in advance.
• DDS discovery blocked. Laptop firewalls and managed networks can block multicast or UDP traffic used by default ROS 2 DDS discovery. Solution: allow the required DDS traffic, use a network approved for the test, or configure an alternative discovery approach supported by your ROS 2 middleware.
• Nav2 parameter mismatch. Default footprint, inflation and obstacle-layer values may not match the rover, its sensors or the environment. The rover may refuse to plan through a doorway if its configured footprint and inflation radius make the passage appear impassable.

None of these are Leo Rover specific. They appear on many ROS 2 mobile platforms. Knowing they exist in advance can shorten the onboarding process substantially.

Frequently asked questions

Q: Can a complete ROS 2 beginner finish this in one afternoon?

A: Realistically, it is possible but not a safe assumption. A beginner should budget at least two days: one for ROS 2 fundamentals and network setup, one for teleoperation, mapping, and Nav2. The 4 to 6 hour timeline assumes basic familiarity with the terminal, colcon, and RViz2.

Q: Do you need the charger fully finished before starting?

A: Not necessarily, but do not assume the rover arrives with sufficient charge for driving. Check the battery indicator and supplied documentation, start charging on arrival, and run software setup in parallel where safe to do so.

Q: What if the lab has no gamepad?

A: Use another teleoperation method supported by your rover configuration, such as a keyboard teleop node or an available browser-based control interface. A browser-based virtual joystick is slower for mapping runs but can be sufficient for a first drive.

Q: Does the timeline change for outdoor autonomous runs?

A: Yes. GNSS-based navigation may require antenna mounting, clear sky visibility, corrections or an RTK setup where applicable, frame configuration, and validation of position quality. Add time for testing in the actual outdoor environment. Field robotics runs also benefit from a longer teleoperation phase to characterize terrain.

Q: Is ROS 1 supported?

A: ROS 1 Noetic reached end of life in May 2025. Legacy ROS 1 packages may still be available, but new deployments should use a supported ROS 2 configuration and verify compatibility with the current Leo Rover documentation.

Q: What happens if colcon build fails on a fresh system?

A: A common cause is missing rosdep dependencies or an uninitialized rosdep installation. Run rosdep update and then rosdep install --from-paths src --ignore-src -r -y again. If the failure persists, check the build log for the first error, not the last.

Q: How much of this is reproducible for a class of ten students?

A: The rover setup can be reproduced for each team, provided that network access, charging, navigation sensors and operator laptops are prepared in advance. At scale, the common bottlenecks are network configuration, available gamepads, charging capacity, and laptop setup. Preparing a dedicated router and pre-imaging student laptops with the required ROS 2 version can reduce delays.

Step-by-step commands, launch files, compatibility information and troubleshooting notes for the current software versions are maintained at docs.fictionlab.pl. Check them before delivery arrives so the afternoon is spent driving, not reading. If you are still evaluating hardware options, the current lineup is available in the Fictionlab shop.