# aruco_ros publishes marker poses for a single tag or a whole board

> aruco_ros is a ROS package wrapping the Aruco fiducial marker detector, publishing a pose and a confidence value per marker over a custom message. It is MIT licensed, it has no GitHub releases, and its documented walkthrough still runs against the REEM robot and the Kinetic-era API.

**pal-robotics/aruco_ros** — Software package and ROS wrappers of the Aruco Augmented Reality marker detector library

- Repository: https://github.com/pal-robotics/aruco_ros
- Stars: 611 · Forks: 339
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/pal-robotics-aruco-ros

## A detection library with a ROS message contract around it

aruco_ros is a software package and set of ROS wrappers for the Aruco augmented reality marker detector library. The wrapping is the point. Aruco itself is a computer vision library for detecting fiducial markers, and the paper it cites describes automatic generation and detection of highly reliable fiducial markers under occlusion. What aruco_ros adds is the ROS surface: a message type carrying a pose, a marker identifier and a confidence, plus nodes that fill it in. The repository layout is three packages side by side, `aruco/` for the vendored or wrapped library, `aruco_msgs/` for the message definitions and `aruco_ros/` for the nodes and launch files. For a robotics team, the value is not the detection algorithm, which you could also call directly, but the fact that a camera driver, a detector and a subscriber can agree on a message type without anyone writing the serialisation.

## The message carries a confidence value, not just a pose

The message definition is short and each field has a purpose. The `aruco_ros/Marker` message carries a standard `Header`, so the pose arrives with the timestamp and the frame the consumer expects, a `uint32 id` for the marker identifier, a `geometry_msgs/PoseWithCovariance` for the position and orientation, and a `float64 confidence`. That last field is the interesting one, because a marker detector will happily report a pose for a detection it is not certain about, and without a confidence figure a consumer cannot distinguish a solid lock from a noisy one. `aruco_ros/MarkerArray` bundles a list of `Marker` messages under one header, which is the shape you want when several tags are visible at once, for example on a board. A pose with covariance rather than a bare pose is the other deliberate choice, because camera-based pose estimation is never exact and a consumer doing control on top of it needs to know how much to trust the number.

## Boards give better precision than a lone marker

The features list names the technical trade-off the project is built around. High-framerate tracking of AR markers is the headline, and marker generation with a given size, optimized for minimal perceptive ambiguity when there are more markers to track, is what makes that possible in a cluttered scene. The third feature is the important one for anyone considering this: enhanced precision tracking by using boards of markers. A single tag gives you a limited set of detectable corners, and its pose estimate degrades quickly as the tag tilts away from the camera or moves out of frame. A board of several known tags, with a known geometric arrangement, gives the solver more constraints and a better conditioned estimate. The applications the README lists follow directly from that: object pose estimation, and visual servoing where you need to track an object and a hand at the same time, which means two detections in one frame, which is where a marker array rather than a single message becomes necessary.

## Running the single marker node end to end

The documented walkthrough is specific and worth following literally. It starts with a REEM robot in simulation with a marker floating in front of it, which also starts the robot's stereo cameras, and notes that an extra light source had to be added because the default world is dark. The launch command is below, and the frame in which the pose is reported is chosen with the `ref_frame` argument.

```bash
    roslaunch aruco_ros single.launch markerId:=26 markerSize:=0.08 eye:="right"
```

```bash
    roslaunch aruco_ros single.launch markerId:=26 markerSize:=0.08 eye:="right" ref_frame:=/base_link
```

The `single` node tracks the specified marker and publishes its pose in the camera frame, and with `ref_frame` set to the robot's `base_link` the pose is published with respect to that frame instead. The undistorted images come from the `image_proc` node, run under the camera's namespace.

```bash
    ROS_NAMESPACE=/stereo/right rosrun image_proc image_proc image_raw:=image
```

And the result is visible in `image_view`, with the topic `aruco_single/result`.

```bash
    rosrun image_view image_view image:=/aruco_single/result
```

The `markerSize` argument is where you declare the physical size of your tag, and getting that number wrong scales every pose the node publishes, so it is the parameter to check first when a position looks plausible but wrong.

## The coordinate convention change is a consumer-side breaking change

The README documents a breaking change under a heading for the Kinetic release, and it is the kind of detail that breaks a working system. The Aruco library was updated to version 3.0.4, and the coordinate system was changed to match the library's. The convention follows rviz conventions, with X in red, Y in green and Z in blue, and the repository carries an image showing the new coordinates. Any node that consumed the pose before this change and assumed the old axes is now silently wrong, and worse, wrong in a way that can still look plausible on one axis. This is worth flagging in any integration plan, because the fix is not obvious from a bad pose estimate, it is a matter of knowing the convention changed. The marker images in `etc/` and the `marker_in_hand.jpg` reference in the features section suggest the project expects you to generate your own tags and print them, since marker generation with a given size is one of the listed features.

## A package with no releases and a dated branch name

The maintenance picture is mixed, and it is worth reading the facts rather than guessing. The default branch is `humble-devel`, which points at a ROS 2 Humble line of development. The repository has no GitHub releases, so there is no version to pin and no changelog to read for what changed. The last push was on 2026-10-07. Meanwhile, the documented walkthrough uses ROS 1 style commands, `roslaunch` and `rosrun` with `ROS_NAMESPACE`, and the example assets reference the REEM robot, which is a research platform from the same group, PAL Robotics. The topics list `aruco`, `aruco-detector`, `aruco-library`, `aruco-marker-detection`, `aruco-ros`, `fiducial-marker`, `robot`, `robotics` and `ros`. The practical reading is that the package carries both a ROS 1 history and a ROS 2 branch, and the documentation still shows the older style, so if you are on ROS 2 you should confirm the node names and topics in the branch you actually have. The licence is MIT, which means no copyleft obligations on the code you build with it, and the paper the detection library is based on is cited in the README.

## Conclusion

Adopt aruco_ros when your robot needs pose estimates from printed fiducial markers and you want a ready ROS message contract rather than a detection loop you write yourself. Skip it if your stack is ROS 2, since the default branch here is humble-devel and the documented example commands are ROS 1 style, or if you need multi-camera calibration and timing that the package does not describe. Before you start, verify the marker size units against your physical tags, since markerSize is given as a plain number in the launch arguments, and read the coordinate convention change, because the frame in which the pose is reported changed in a way that breaks existing consumer nodes.

## FAQ

### What does the aruco_ros Marker message contain?

A `Header`, a `uint32 id`, a `geometry_msgs/PoseWithCovariance` and a `float64 confidence`. The `aruco_ros/MarkerArray` message bundles a list of `Marker` messages under one header, for when several markers are visible.

### How do I publish a marker pose in the robot base_link frame?

Pass the `ref_frame` argument to the single node launch file, for example `roslaunch aruco_ros single.launch markerId:=26 markerSize:=0.08 eye:="right" ref_frame:=/base_link`.

### What changed in aruco_ros for the Kinetic release?

The Aruco library was updated to version 3.0.4 and the coordinate system was changed to match the library's, following rviz conventions with X in red, Y in green and Z in blue.

### Does aruco_ros use boards of markers for better precision?

Yes. The feature list names enhanced precision tracking by using boards of markers, alongside high-framerate tracking of individual AR markers.

## Sources

- [Issues](https://github.com/pal-robotics/aruco_ros/issues)
- [License: MIT](https://github.com/pal-robotics/aruco_ros/blob/humble-devel/LICENSE)
- [pal-robotics/aruco_ros on GitHub](https://github.com/pal-robotics/aruco_ros)
- [README](https://github.com/pal-robotics/aruco_ros/blob/humble-devel/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pal-robotics-aruco-ros