Skip to main content
By the end of this guide you will have run a saved route and checked whether the robot arrived. First create a mission in the editor if your map does not have one yet. Download this guide as a notebook

1. Connect to your robot

Start in a project folder with a GRID development session:
Keep that CLI process running. Use its workspace .venv Python environment (or select that kernel if you use the downloadable notebook). Run the snippets in order in one Python session. Set your registered robot name and use the numbered selectors. The robot must have navigation enabled. Attach navigation and check whether someone is already running a mission. Attaching does not start a mission. A no-option attach shares an existing Nav; it does not create an isolated controller.

2. Choose a completed map and saved route

Select a completed map of the robot’s actual surroundings. Change MAP_PAGE if it is on another page.
Choose the saved mission you reviewed in the editor. Change MISSION_PAGE if needed.
The selection stores the mission ID, so duplicate names do not select the wrong record.

3. Start navigation and verify localization

Start loads the map and waits for localization; it does not execute a route. The viewer opens in your browser. Compare its robot marker and heading with the physical robot. localize() then waits for a fresh accepted localization fix, and home keeps that map pose for a possible return trip.
home.x and home.y are metres in the map frame; home.yaw is radians. If localization fails or the marker is wrong, stop here and use troubleshooting. A successful API response does not replace checking that you selected the correct physical map.

Check the live view

Check the connection state and the age of the displayed pose. A connected robot can still have stale position data. Compare the marker and heading with the physical robot. Keep this page open while the mission runs. Opening or closing it does not start or stop motion.

4. Execute the saved mission

Position the robot at the saved route’s intended start and review the path in the editor. This call commands motion. Keep the e-stop accessible; type RUN only after checking the route. The call blocks until the run finishes.

Watch progress and check the result

While the Python call waits, watch the browser view. The map shows the planned route, driven path, robot position, and current target when those streams are available. Check progress through the stops. Missing data does not prove that the robot is stationary. A stopped marker or a finished progress bar is not proof of success. Completion is not automatically success: the returned MissionResult can be succeeded, cancelled, or failed. Its message explains the result and final_pose contains the final pose when available. A timeout does not prove that the robot rejected the request; check status before retrying.

Cancel if needed

To cancel a blocking notebook call, interrupt the running cell. The remote client requests cancellation on interruption. Then check the physical robot. A busy kernel cannot run another cell until the current call returns or is interrupted. When the kernel can accept a command, nav.cancel_mission() requests cancellation and keeps localization available. A successful request alone does not confirm a stop. If stopping cannot be confirmed, use the physical e-stop and involve the operator. Closing the viewer does not cancel navigation. For layers, logs, and stale data, see Telemetry UI.

5. Finish

Shutdown releases the shared Nav instance and affects other clients attached to it. Collect results first, then release navigation before the borrowed robot. Run this cleanup even after an earlier step fails. If a connection failure prevents stopping motion, use the robot’s e-stop.
Continue with planning your own routes, or choose configuration overrides before creating your next Nav.