1. Connect to your robot
Start in a project folder with a GRID development session:.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. ChangeMAP_PAGE if it is on another page.
MISSION_PAGE if needed.
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 returnedMissionResult 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.