English
Español
Português
Deutsch
한국어
日本語
Italiano
Français
العربية
Türkçe
Mobile manipulator perception connects two jobs that are easy to confuse: reaching a work area and understanding it well enough to manipulate an object. A mobile robot arm may arrive near the right shelf yet still need a fresh view of the target and a suitable working position. Navigation success is therefore not, by itself, permission to begin a pick.
What changes when the arm is no longer fixed?
At a fixed workstation, the base of the arm can have a defined relationship to the work area. On a mobile platform, the proposal must also account for where the base stops and what the robot can see from that position. The object may be visible but outside the usable reach of the current arrangement, or reachable from another position but hidden from the current view.
| Question | Fixed-workstation starting point | Additional mobile question |
|---|---|---|
| Where is the arm? | A specified mounting location | How does the arrival position relate to this work area? |
| What can the camera see? | A planned view around the station | Does the new position still provide a useful view? |
| Can the task be attempted? | The configured workspace and task constraints | Does the current base-and-arm arrangement meet those constraints? |
| What information is current? | Observations associated with this operation | Which observations need refreshing after movement? |
This comparison is a way to organise design questions, not a claim that fixed cells never change or that a mobile base always needs to reposition.
An example: collecting a component from a shelf
The following is a concept scenario. Assume a mobile platform carries an arm and the intended task is to collect one component at a named station. No particular navigation accuracy, grasp success or MScape deployment is assumed.
- Arrive: the navigation system reports its state at the intended work area.
- Observe: the application obtains an appropriate view of the station and target.
- Decide: the task system determines whether the available information and arrangement permit the planned operation.
- Act and check: the assigned robot systems execute the approved task, and the application records the agreed evidence of its result.
If the target is hidden, the next useful step may be another observation rather than immediate manipulation. If the working position is unsuitable, a repositioning decision belongs to the overall motion and task design. Neither issue should be treated as a reason to proceed with stale observations.
Separate navigation, observation and manipulation
MoveIt’s official mobile-base-and-arm example distinguishes coordinated base-and-arm planning from pure navigation, for which it points to Nav2. That is a useful conceptual boundary, not a recommendation that these software packages are ready to run on a particular computer without integration.
For a solution discussion, ask what each subsystem reports to the next. “Arrived” should have a defined meaning. An image should be associated with the relevant task and observation time. A manipulation request should not silently assume the scene is unchanged since the robot approached.
The planning scene concept provides another useful distinction: the application needs a representation of its surroundings as well as the robot’s state. Having a camera stream is not the same as having all the information required for a movement.
One computer or separate computing roles?
A shared onboard computer may be a candidate when the selected software and hardware can support the combined tasks. Separate computing nodes may be appropriate when subsystems have different interfaces or support responsibilities. Neither arrangement is automatically better.
With a shared system, clarify which workloads run together and what happens when one becomes unavailable. With separate systems, clarify the information exchanged between them and how the application recognises an outdated or missing result. These are design responsibilities; this article does not prescribe a safety response.
What belongs in an early requirements brief?
Describe the stations the robot visits, the object-handling task at each station, the views needed after arrival and the information passed between navigation and manipulation. Add known camera interfaces, installation space and power constraints. Leave unresolved details explicitly open for the system designer.
The MScape N Series can be considered for the onboard AI-computing portion where a verified configuration fits. The computer is not a complete navigation, manipulation or safety solution. Specific software, camera and robot interfaces require confirmation.
Keep the two questions separate
First ask whether the robot is ready to work from its current position. Then ask how the pick will be understood and checked. The robotic picking vision article covers that second question without repeating the mobile-navigation discussion.
