adi_iio - ROS2 Package for IIO Integration

::: {.contents depth=”2”} :::

Overview

The adi_iio package bridges the gap between Analog Devices’ IIO hardware and the ROS2 ecosystem. It provides robust, easy-to-integrate interfaces for sensor data acquisition and real-time processing, enabling rapid development of advanced robotics and automation applications.

By facilitating seamless communication and data exchange between IIO devices and ROS2 nodes, the package serves as a comprehensive framework for integrating industrial I/O systems into modern robotics solutions. It provides a collection of services to read/write IIO attributes, and manage IIO buffers. You can also attach topics to the attributes/buffers

This project is intended for both internal developers and external contributors seeking to leverage Analog Devices’ IIO devices within ROS2 environments.

Getting Started

To help you quickly get started with the adi_iio package, we have organized detailed documentation into several sections:

• For information on prerequisites, repository setup, and building the package, refer to the Installation section.
• The Examples Introduction{.interpreted-text role=”ref”} provides an overview of the available examples. Start with the Service Call Reference{.interpreted-text role=”ref”} to use the ROS2 services. You can also reference the standalone nodes and launch files for specific hardware interaction.
• For information on parameters and services, refer to the Node Description section.
• System Tests: The package includes comprehensive system tests located in the test/ directory. These tests are integrated with colcon test and require specific hardware (Analog Devices IIO devices) to execute. Refer to the test directory's README for detailed setup instructions and execution guidelines.
• For building this documentation, refer to Building the Project Documentation Locally.

Getting Help

• Issue Tracker: Report bugs, request features, or submit technical queries via our Issue Tracker.
• Further Guidance: For additional communication guidelines, refer to COMMUNICATION.

Contributing

Contributions are key to our project’s success. Before submitting changes:

• Familiarize yourself with our code and testing conventions.
• Consult the CONTRIBUTING for detailed instructions.
• Ensure your code adheres to our design values and guidelines.

License

This project is licensed under the Apache License, Version 2.0.

The product makes use of third party and open source software. The licenses and notices for this software are listed at: iio_ros2 - Third Party and Open Source Software.

CHANGELOG

Refer to our CHANGELOG for version history and release notes.

Installation

This section describes how to install the required software to run the adi_iio package.

Prerequisites:

Before installing the adi_iio package, ensure you have the following:

• A compatible version of ROS2 installed (e.g., humble). See the ROS2 Humble Installation Guide for instructions.
• The libiio v0 library installed in the Host (e.g.: x86_64 host running Ubuntu 22.04) as well as the target (e.g.: Raspberry Pi 4). It can be automatically installed via rosdep in systems where ROS2 is installed. Alternatively, you can build a specific version of it from source using the provided installation script (see (Optional) Build libiio from sources).

File truncated at 100 lines see the full file

Contributing Guidelines

Thank you for your interest in contributing to iio_ros2. Whether it’s a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

• Contributing Guidelines
  • How to Contribute
    • Contributing source code
      • Code Style
      • How to Contribute Source Code
      • Pull Request Rules
    • Bug reports
      • Before Submitting a Bug Report
      • How to Submit a Good Bug Report
    • Feature Requests
      • Before Submitting an Enhancement Suggestion
      • How to Submit a Good Enhancement Suggestion
    • Contributing documentation
      • Documentation Best Practices
  • Becoming a Trusted Committers
  • Licensing
  • Resources:

How to Contribute

Contributing source code

We follow a development process designed to reduce errors, encourage collaboration, and make high quality code. Review the following to get acquainted with this development process.

Code Style

To ensure consistency and maintain high quality across the project, please adhere to the following practices:

• It is recommended to create a Python3 virtual environment (vevnv) to manage and keep your development environment isolated

• The project follows the ROS2 coding style. This ensures that code is written uniformly and is easily maintainable.

• Install a ROS distribution and source the underlay to access the Ament Lint CLI Utilities.

• A pre-commit configuration file is provided, which includes hooks that automatically check code compliance.

  • Important: Hooks that modify file content need to be executed manually by the developer. The default hooks only perform checks.

  • For issues that can be automatically resolved, a make fix target is available. It is recommended to run this target manually to apply automatic corrections before you commit changes.

How to Contribute Source Code

• Create a fork of this repository. This will create your own personal copy of the package. All of your development should take place in your fork. If you are not sure how to do this, check out GitHub help

  • Create a create a remote pointing to the upstream remote repository.

  • Work out of a new branch, one that is not a release main branch, ideally a develop branch targeted for the currently supported ROS distribution, such as humble-develop. Remember to periodically rebase to have the latest code available.

• Write your code and remember to:
  • Always keep your branch updated with the original upstream.
  • Always sign-off you commits.
  • Run make fix before committing changes and make fixes according to the guidelines.
  • Look at the existing code and try to maintain the existing style and pattern as much as possible.

• Resolve compiler warnings or at least make sure you code does not add new ones.

• Submit a pull request to the upstream repository following the PR rules.

• Check Continuous Integration (CI): the moment you submit a pul request, a few jobs will be started which try to compile the code and run automated tests. Pay attention to any CI failures reported in the pull request, and stay involved in the conversation. On the Github UI, checks can be:
  • ✅: Passed, all good!
  • 🟡: Pending, results haven’t been received yet.
  • ❌: Failed, something is wrong.

Pull Request Rules

• Commit message includes a Signed-off-by: [name] < email > to the commit message. This ensures you have the rights to submit your code, by agreeing to the Developer Certificate of Origin. If you can not agree to the DCO, don’t submit a pull request, as we can not accept it.

  • DCO is a declaration of ownership, basically saying that you created the contribution and that it is suitable to be covered under an open source license (not proprietary).

  • If your user.name and user.email configurations are set up in git, then you can simply run git commit -signoff to have your signature automatically appended.

• Commit should be atomic, meaning it should do one thing only. A pull request may contain multiple commits if necessary to fix a bug or implement a feature.

File truncated at 100 lines see the full file