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.
Start with the system, not the movement
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:
- The expected software build is running.
- The correct device is connected.
- The expected serial port is being used.
- The required ROS 2 nodes are alive.
- The expected topics and services are available.
- The configuration matches what was tested.
- The homing configuration is correct.
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.
Homing is one of the first things I'd test
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.
A healthy ROS 2 graph doesn't necessarily mean a healthy robot
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:
- The correct physical robot is connected;
- The correct serial device is being used;
- The robot is in the state you expect;
- The calibration is correct;
- The physical setup matches your assumptions.
That's an important distinction.
I tend to think about it in three layers
When I think about validating a robotic system, I find it useful to separate things into three layers.
1. Software
First, check the software itself.
Things like:
- ROS 2 distribution
- package/build version
- launch files
- nodes
- topics
- services
- parameters
- configuration files
The question here is:
Does the software match what I intended to run?
2. Integration
Then look at the connection between the software and the robot.
For example:
- Is the expected serial device connected?
- Is the correct port being used?
- Is the robot interface available?
- Are the expected publishers present?
- Are the required services available?
- Is the calibration/configuration what I expect?
Now the question becomes:
Does the software appear to be connected to the hardware? I think it is?
3. Physical execution
Only after that do we get to the actual movement. This is where I'd test things like:
- Does homing behave as expected?
- Do the joints move correctly?
- Does a Cartesian command produce the expected movement?
- Does the physical distance match what the software expects?
- Are there unexpected movements?
- Are the workspace boundaries respected?
And this is where an important distinction comes in:
Passing the first two layers doesn't automatically prove the third.
Why I like Cartesian tests
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.
Then AI enters the picture
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:
- inspect the ROS graph;
- read configuration;
- analyse logs;
- compare expected and actual interfaces;
- identify missing dependencies;
- prepare a movement command;
- propose a test.
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.
Don't claim more than you tested
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.
So what should happen before the next action?
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.
