Before You Move the Robot, Prove You’re Talking to the Right Robot

A developer who has worked with the Dobot Magician robot arm on ROS 2 outlines a layered pre-flight validation approach that must be completed before sending a robot its first movement command. The method separates software checks (node, topic, and service lists, launch status) from software-to-hardware connection checks and physical movement tests, arguing that passing the first two layers does not prove the third. The developer recommends validating the homing recipe before executing it and using Cartesian commands to compare intended displacement against actual physical movement, a concern that grows sharper when AI agents drive physical hardware.

Recently, I was asked a pretty simple question: What would you check before sending the first movement command to a Dobot Magician running through ROS 2? Since I've worked with the Dobot Magician myself, I've started thinking about the checks I normally do before letting the robot move. Is the build correct? Is the right port connected? Are all the nodes running? Is the robot publishing what it should? Did any node die during startup? Is the homing configuration correct? For smaller ROS 2 projects, I also find rqt graph really useful for quickly checking that everything is connected as expected. The more I thought about the question, though, the more I realised that this isn't really just a Dobot problem. It's a much bigger question when software, especially AI-driven software, starts interacting with physical hardware. When working with a physical robot, I don't think the first question should be: "What command should I send?" It should be: "What do I actually know about the system right now?" For one of my Dobot setups, I'd want to establish a few things before sending a movement command: Most of these checks don't require the robot to move at all. And that's important. There is a difference between checking what the software thinks is happening and actually making the robot do something. One of the tests I commonly use with the Dobot is homing using a predefined configuration. In my ROS setup, I use a separate service for the homing sequence, with limits set by the Dobot Magician API. Depending on how the nodes are implemented, homing can also be useful for re-evaluating the reported joint angles afterwards. But there are still two separate things happening here. First, I can inspect the homing configuration and ensure the recipe is correct. Then I can actually run it on the robot. Those are not the same test. I can verify the recipe without proving anything about the physical movement. So I think of it as: Validate the recipe first. Then, validate the execution. This was probably the part that made me think about the problem more deeply. Imagine running: ros2 node list ros2 topic list ros2 service list Everything looks normal. Your nodes are running, the expected topics exist, the launch file completed successfully, and nothing appears to have crashed. It would be very easy to think: "We're good to go." But what have you actually proved? You've proved that the software environment looks right. You haven't necessarily proved that: That's an important distinction. When I think about validating a robotic system, I find it useful to separate things into three layers. First, check the software itself. Things like: The question here is: Does the software match what I intended to run? Then look at the connection between the software and the robot. For example: Now the question becomes: Does the software appear to be connected to the hardware? I think it is? Only after that do we get to the actual movement. This is where I'd test things like: And this is where an important distinction comes in: Passing the first two layers doesn't automatically prove the third. Once I get to physical testing, I particularly like using Cartesian movement for validation. With a joint command, I know that I asked a particular joint to move. With a Cartesian command, I have a physical position to reason about. For example, if I command a known displacement, I can compare what the software asked the robot to do with what actually happened in physical space. So you get something like: Command ↓ Robot state ↓ Physical movement That gives you another independent way of checking whether your assumptions match reality. Of course, successfully testing one movement doesn't prove that every possible movement is safe. It just gives you evidence about that particular test. And that's really the point. This becomes much more interesting when an AI agent is involved. Imagine an AI agent that can inspect your ROS 2 workspace, read configuration files, launch nodes, analyse logs and eventually send commands to the robot. The workflow could easily become: AI checks the system ↓ AI decides everything looks good. ↓ AI sends a command ↓ Robot moves But there is a missing question: What evidence should allow the AI to cross the boundary between observing the system and physically acting on it? An AI's ability to generate a valid ROS command doesn't necessarily mean it should be granted permission to execute it. For example, I can imagine an AI being allowed to: Physical execution can then sit behind another boundary where additional checks or human confirmation are required. That separation becomes pretty important once software is no longer just producing text or code, but controlling something that can physically move. This is probably the biggest lesson I took from the whole discussion. If I verify that the expected ROS 2 nodes are running, then that's what I've verified. I shouldn't turn that into: "The robot is safe." If I successfully run a homing sequence, I've tested that particular sequence on that particular setup. That doesn't mean every future movement is safe. And if I test one Cartesian movement and measure the result, I've gathered evidence about that movement. I haven't validated the entire workspace. I think it's surprisingly easy to blur these boundaries when developing robotics software, especially when everything appears to be working. I've started thinking about robotic validation less as: "Is the robot safe?" and more as: "What have I actually verified, and what does that evidence allow me to do next?" If I've only verified the software configuration, I shouldn't treat it as evidence of physical movement. If I've verified the software-to-hardware connection, I can move on to a controlled physical test. If I've physically tested a particular movement, I have evidence for that movement, not necessarily everything else. Every step should be based on something we've actually established rather than an assumption that happened to be true during the previous test. And I think this will become increasingly important as AI moves from helping us write robotics software to actually operating robots. The robot doesn't care how confident the software sounds. It only responds to what we actually told it to do.